From owner-ipsec@lists.tislabs.com Wed Dec 1 10:03:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24132; Wed, 1 Dec 1999 10:03:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05389 Wed, 1 Dec 1999 10:57:38 -0500 (EST) Message-ID: <3845466D.E733AB49@redcreek.com> Date: Wed, 01 Dec 1999 08:01:49 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, Paul Hoffman wrote: > Well, I'm not a fan of beating a dead horse, but I don't think this > discussion has come to resolution on a not-necessarily-rare prospect. After giving this some more thought, I think you're right. My apologies to Slava. > If an > implementation lets an IKE SA die without tearing down all IPsec SAs that > were started under its protection, there's going to be the problems that > have been long discussed. I don't agree with this. If I rekey the IKE SA (i.e. let the old one die and negotiate a new one to the same intermediary, and with the same authentication characteristics as the old one), I think these are equivalent. If I defer this negotiation for some period after the old one dies, and then instantiate the equivalent IKE SA at some future time (e.g. when something forces activity, such as a phase 2 rekey/delete), what is the difference? > An implementation can (and IMO SHOULD) choose not create IPsec SAs that > have lifetimes longer than the IKE SA under which they are protected. So > far, so good. I also disagree with this (with that statement that it SHOULD), but I can see why one might believe this. I think the basic premise is that once the phase 1 SA is gone, if the authentication credential is revoked, there is no way to tie this to the phase 2 SA, or at least I think that's an argument that's been posed. However, this is only true if you do not bind the authentication credential to the phase 2 SA to begin with, via your policy. If the credential is bound to the phase 2 SA, then the recognition of revocation permits (at least) the unilateral deletion of the phase 2 SA. That is, if the other end's cert is revoked and you know a phase 2 SA relies upon it, you can delete the phase 2 SA, even if you cannot notify the other side. And in this case, why should you care (much) if you are unable to notify the other side? Granted, this requires a level of sophistication which surpasses that of many fielded implementations. The problem is (I think), that many implementations use only one credential for the sgw, and with this authenticate all resulting phase 2 SAs. Even in this case, though, recognition of revocation should be sufficient to permit unilateral deletion of all relevant phase 2 SAs. > However, there are some cases where an IKE SA can get taken down > unexpectedly. A good example is when the IKE SA discovers that the cert it > used to authenticate the other party has been compromised. In this case, > all the IPsec SAs are suspect and should be deleted. Yes, this is the case just referred to above, and I agree. > I may have missed it, but is there a good reason why an IKE implementation > that is deleting an IKE SA for security reasons ever want *not* to tear > down the IPsec SAs that it created? Probably not. Scott From owner-ipsec@lists.tislabs.com Wed Dec 1 10:15:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24339; Wed, 1 Dec 1999 10:15:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05437 Wed, 1 Dec 1999 11:20:29 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788E84@md-exchange1.nai.com> From: "Mason, David" To: "'Jan Vilhuber'" , Slava Kavsan Cc: Paul Koning , ddp@network-alchemy.com, ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Wed, 1 Dec 1999 08:21:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Until acknowledged delete notifies are deployed you could renegotiate, send the delete, and still end up with the same situation as if you didn't bother to renegotiate and send the delete. One possible solution is to only renegotiate and send a delete if you continue to receive "dead spis" from the peer (but this has the drawback of having to retain peer information after the IKE SA is deleted on security gateways for the peer-road-warrior case - a client would normally not receive traffic from a gateway after it has stopped sending traffic except for possibly a trailing packet or two that could just be dropped). -dave -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Tuesday, November 30, 1999 7:16 PM To: Slava Kavsan Cc: Paul Koning; ddp@network-alchemy.com; ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation On Tue, 30 Nov 1999, Slava Kavsan wrote: > The issue still remains, though: > > "When deleting all SAs - in order to delete "orphan" IPSec SAs - starting > re-negotiation of IKE SA seems kinda silly when the goal is to kill all > SAs." > If you want to be a nice net-citizen, and interoprate cleanly and robustly, then you should renegotiate the phase 1 to securely let the other end know that it should delete it's phase2's also. You can then proceed to also delete your phase1 (after sending a delete for the same ;). Thus, you now have a clean ending of all connections. I don't really see a problem with this. jan > (I also assume that there is no "step-parent" IKE SA exists with the same > peer to "adapt" these "orphans") > > > > > Paul Koning wrote: > > > >>>>> "Derrell" == Derrell D Piper writes: > > > > >> b) re-negotiate IKE SA before sending DELETE > > Derrell> ...which would beg the question of whether or not it's legal > > Derrell> to send an IPSEC DELETE on an IKE SA that did not originally > > Derrell> negotiate the IPSEC SA's. Our particular implementation > > Derrell> would accept that, but I can also see an argument for while > > Derrell> that's not right. > > > > I think it has to be accepted. > > > > Reasoning: either phase 2 SAs are bound to phase 1 SAs or they are > > not. > > > > If they are, then the phase 2 SAs go away when the phase 2 SA does, > > and it is reasonable to require messages relating to the phase 2 SAs > > to come over the phase 1 SA to which they are bound. > > > > If they are not, then the phase 1 SA may disappear without affecting > > the phase 2 SAs. But also, if they aren't bound, then it is illogical > > to require messages about the phase 2 SA to arrive via the phase 1 SA > > that created it, because by definition there wasn't any such binding. > > And never mind that abstract argument... if you make that restriction > > then it follows that you can no longer send ANY messages about the > > phase 2 SA once the original phase 1 SA disappears. That defeats the > > purpose of the non-binding approach! > > > > Since IKE is defined the latter way (no binding) messages such as > > deletes of a phase 2 SA must be accepted on any phase 1 SA (from the > > right source, obviously). > > > > paul > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-539-4816 > http://www.ire.com > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 1 11:03:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26359; Wed, 1 Dec 1999 11:03:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05651 Wed, 1 Dec 1999 12:25:48 -0500 (EST) Date: Wed, 1 Dec 1999 12:29:12 -0500 Message-Id: <199912011729.MAA17691@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> <384463D7.8DCCB044@redcreek.com> <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman writes: Paul> At 03:55 PM 11/30/99 -0800, Scott G. Kelly wrote: >> I think this misses the point: this is a pathological case which >> should occur only rarely. I don't think that the implications of >> requiring the binding are justified by this rare case. I will >> again point out that nobody has 'fessed up to summary deletion of >> phase 1 SAs once phase 2 SAs are established, despite the fact >> that we've been beating this into the ground for over a year >> now. I take that to mean that nobody does it, and I fail to >> understand why we don't move on. Paul> Well, I'm not a fan of beating a dead horse, but I don't think Paul> this discussion has come to resolution on a Paul> not-necessarily-rare prospect. If an implementation lets an IKE Paul> SA die without tearing down all IPsec SAs that were started Paul> under its protection, there's going to be the problems that Paul> have been long discussed. ... Paul> I may have missed it, but is there a good reason why an IKE Paul> implementation that is deleting an IKE SA for security reasons Paul> ever want *not* to tear down the IPsec SAs that it created? Probably not, but "for security reasons" is only one of the possible reasons for taking away the IKE SA. That being the case, there are legit reasons (resource constraints, for example) where the IKE SA goes away before the end of lifetime of the phase 2 SAs. So the issue Slava raised is possible in practice. I can't see it as a big concern, though. paul From owner-ipsec@lists.tislabs.com Wed Dec 1 14:53:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29997; Wed, 1 Dec 1999 14:53:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06538 Wed, 1 Dec 1999 16:17:47 -0500 (EST) Date: Wed, 1 Dec 1999 15:20:41 -0600 (CST) From: Tylor Allison X-Sender: allison@stpsowk07.sctc.com To: ipsec@lists.tislabs.com cc: allison@securecomputing.com, carney@securecomputing.com Subject: matching GW addr to ID payload (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question that I hope some of you out there can help me answer. The scenario is this: Say I have a host machine using IKE/IPSEC which has multiple aliases for the same interface (or multiple interfaces routable to the same remote peer). When I start a IKE negotiation to the remote peer the IKE implementation does not have control over which interface address gets inserted in the UDP packet. If I wish to use an IPV4 address in the identity payload, my IKE implementation will choose the IPV4 address to use in the ID payload based on the IKE implementations configured policy. My question is, what happens if the IPV4 address selected in the ID payload does not match the actual source address contained in the packet? I know for the pre-shared key case, this won't (or shouldn't) work (at least for Phase 1 using Main Mode), since the actual remote address used to send the packet is used to determine the pre-shared key used to authenticate the session. But how should this be handled for signature based authentication? If the IPV4 address specified in the identity payload matches the IP address in the subjectAltName extension of the cert used for sig authentication and this matches the IKE local policy, does it need to match the actual address received from the packet? And what if there is no ip address in the subject-alt name? Is it then a requirement that the actual gateway match the IPV4_ADDR identity? How would implementations out there handle this scenario? Has anyone else thought of how to handle multiple interface aliases so that ISAKMP does "the right thing". Thanks in advance. --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-ipsec@lists.tislabs.com Wed Dec 1 15:56:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00877; Wed, 1 Dec 1999 15:56:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06684 Wed, 1 Dec 1999 17:32:30 -0500 (EST) Date: Thu, 2 Dec 1999 00:35:58 +0200 (EET) Message-Id: <199912012235.AAA26405@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Hoffman Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> <384463D7.8DCCB044@redcreek.com> <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 13 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman writes: > An implementation can (and IMO SHOULD) choose not create IPsec SAs that > have lifetimes longer than the IKE SA under which they are protected. So > far, so good. Why? Is there any reason to tie the IKE and IPsec SA lifetimes together? > However, there are some cases where an IKE SA can get taken down > unexpectedly. A good example is when the IKE SA discovers that the cert it > used to authenticate the other party has been compromised. In this case, > all the IPsec SAs are suspect and should be deleted. Why? If the key was compromised at some point of time, that does NOT mean that old signatures created using that key are not valid anymore, it means the NEW signatures MUST not be accepted after that. If I create an SA from my laptop to corporate firewall using the smartcard I have in the IETF terminal room, and when I turn my back somebody steals the smartcard from the table. When I detect this I immediately of course revoke the certificate of that smartcard, but there is no need to tear down my SAs I have created before the smartcard was stolen. The holder of the smartcard still cannot decrypt my traffic inside the old SAs, so I can use that tunnel I have to get backup method of logging in... :-) Of course I can first set up the backup method and then report the smartcard being stolen, but that will open up more time for the hacker to get into my system. The signature check was done when the IKE SA was created and if the key wasn't compromized at that point then there is no need to delete the SAs. You might want to do it just to be sure. This also depends of the reason why the certificate was revocated. If the certificate was revoked because the employer moved to the other company, you do want to delete all existing SAs also... > I may have missed it, but is there a good reason why an IKE > implementation that is deleting an IKE SA for security reasons ever > want *not* to tear down the IPsec SAs that it created? I agree that there are so few reasons to not to delete the IPsec SAs when IKE SA is deleted because of *security reasons* that we can ignore them. So I think it is ok to tear down all IPsec SAs using IKE SA in that case. There are quite a lot of more reasons to keep IPsec SAs when IKE SA is deleted because of resource limits etc. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 1 17:03:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA02029; Wed, 1 Dec 1999 17:03:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06874 Wed, 1 Dec 1999 18:45:43 -0500 (EST) Message-ID: <3845B2FC.9F2C1A6@ire-ma.com> Date: Wed, 01 Dec 1999 18:45:01 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> <384463D7.8DCCB044@redcreek.com> <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> <199912012235.AAA26405@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The question still remains - how to send DELETE notification when deleting IPSec SA while there is no IKE SAs to that peer. My vote - to re-key IKE SAs as soon as possible after they are expired or deleted (if there are active IPSec SAs with that peer) - so they will be around when I need them, but if for some reason IKE SA cannot be re-keyed - do not send IPSec SA DELETEs. Also, IMHO - deletion of IKE SA should be just that - no consequences for any IPSec SAs. Tero Kivinen wrote: > Paul Hoffman writes: > > An implementation can (and IMO SHOULD) choose not create IPsec SAs that > > have lifetimes longer than the IKE SA under which they are protected. So > > far, so good. > > Why? Is there any reason to tie the IKE and IPsec SA lifetimes > together? > > > However, there are some cases where an IKE SA can get taken down > > unexpectedly. A good example is when the IKE SA discovers that the cert it > > used to authenticate the other party has been compromised. In this case, > > all the IPsec SAs are suspect and should be deleted. > > Why? If the key was compromised at some point of time, that does NOT > mean that old signatures created using that key are not valid anymore, > it means the NEW signatures MUST not be accepted after that. > > If I create an SA from my laptop to corporate firewall using the > smartcard I have in the IETF terminal room, and when I turn my back > somebody steals the smartcard from the table. When I detect this I > immediately of course revoke the certificate of that smartcard, but > there is no need to tear down my SAs I have created before the > smartcard was stolen. > > The holder of the smartcard still cannot decrypt my traffic inside the > old SAs, so I can use that tunnel I have to get backup method of > logging in... :-) Of course I can first set up the backup method and > then report the smartcard being stolen, but that will open up more > time for the hacker to get into my system. > > The signature check was done when the IKE SA was created and if the > key wasn't compromized at that point then there is no need to delete > the SAs. > > You might want to do it just to be sure. This also depends of the > reason why the certificate was revocated. If the certificate was > revoked because the employer moved to the other company, you do want > to delete all existing SAs also... > > > I may have missed it, but is there a good reason why an IKE > > implementation that is deleting an IKE SA for security reasons ever > > want *not* to tear down the IPsec SAs that it created? > > I agree that there are so few reasons to not to delete the IPsec SAs > when IKE SA is deleted because of *security reasons* that we can > ignore them. So I think it is ok to tear down all IPsec SAs using IKE > SA in that case. > > There are quite a lot of more reasons to keep IPsec SAs when IKE SA is > deleted because of resource limits etc. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 1 17:04:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA02052; Wed, 1 Dec 1999 17:04:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06987 Wed, 1 Dec 1999 19:01:18 -0500 (EST) Date: Thu, 2 Dec 1999 02:04:43 +0200 (EET) Message-Id: <199912020004.CAA02172@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Bronislav Kavsan Cc: Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <3845B2FC.9F2C1A6@ire-ma.com> References: <3843FF2D.B77C6051@ire-ma.com> <199911301904.LAA15483@gallium.network-alchemy.com> <199911302244.RAA16462@tonga.xedia.com> <38445631.8073F94F@ire-ma.com> <384463D7.8DCCB044@redcreek.com> <4.2.1.19991130182311.00b88bd0@mail.vpnc.org> <199912012235.AAA26405@torni.ssh.fi> <3845B2FC.9F2C1A6@ire-ma.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bronislav Kavsan writes: > The question still remains - how to send DELETE notification when > deleting IPSec SA while there is no IKE SAs to that peer. I would say you do nothing. Do not rekey IKE, do not send delete. If there is no traffic going on the SA then there is no need to rekey it. This also means that the IPsec SA can only expire because of the seconds limit. This means that the other end has the same lifetime information, thus it is going to expire it at the same time. No problem there. If there is data going on in the IPsec SA, then you need rekeying, thus little before the IPsec SA is going to expire, you recreate IKE SA and then do normal rekeying. No problem there either... So where is the problem? > My vote - to re-key IKE SAs as soon as possible after they are > expired or deleted (if there are active IPSec SAs with that peer) - > so they will be around when I need them, If the other end deleted the IKE SA for some reason (or you deleted it), it normally means that you had some reason for it. It might be that the other end has resource problems, and you are not going to help him if you immediately recreate the IKE SA when you detect that the other end deleted it... I would rather suggest that you should recreate the IKE SA only little before you need it again for rekeying (i.e. when the IPsec SA is going to expire because of the kB limit). There is no need to recreate the IKE SA for sending deletes... > Also, IMHO - deletion of IKE SA should be just that - no > consequences for any IPSec SAs. I agree... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 1 17:59:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03077; Wed, 1 Dec 1999 17:59:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07118 Wed, 1 Dec 1999 19:39:01 -0500 (EST) Message-Id: <199912020039.QAA10972@potassium.network-alchemy.com> To: Bronislav Kavsan cc: Tero Kivinen , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Wed, 01 Dec 1999 18:45:01 EST." <3845B2FC.9F2C1A6@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10969.944095172.1@network-alchemy.com> Date: Wed, 01 Dec 1999 16:39:32 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 01 Dec 1999 18:45:01 EST you wrote > The question still remains - how to send DELETE notification when deleting IP >Sec > SA while there is no IKE SAs to that peer. No, the question is why do you have to send a DELETE notification when deleting IPSec SAs and you have no IKE SAs to that peer. I don't think you do. > My vote - to re-key IKE SAs as soon as possible after they are expired or > deleted (if there are active IPSec SAs with that peer) - so they will be arou >nd > when I need them, but if for some reason IKE SA cannot be re-keyed - do not s >end > IPSec SA DELETEs. Also, IMHO - deletion of IKE SA should be just that - no > consequences for any IPSec SAs. I still think that the problem caused by not being able to send a DELETE notification-- namely, a blackhole-- will only happen in edge conditions and even then the problem will be readily noticible because it requires manual intervention and the box on which the manual intervention is done will start filling the event log with messages which should clue in any cluefull operator that that command he just typed is doing something bad. Further manual intervention will rectify the situation; problem solved. In most cases the SAs will naturally be reestablished on their own and no blackhole will happen. Re-establishing an IKE SA for the sole purpose of "so [it] will be around when I need [it]" is not really a reason. It should be established if it really is necessary like having to re-key the IPSec SAs to that peer. And in that case you won't necessarily know that the IPSec SAs will need to be reestablished when the IKE SA dies, you'll only know when the IPSec SAs actually approach expiry. If they do need to be rekeyed an "establish SAs with peer" message will be sent up to IKE who'll notice he has no phase 1 SA with that peer and re-establish it then (and then satisfy the request for IPSec SAs). If they don't need to be rekeyed then that is because they're not being used and when they die a quiet death no one will notice. If negotiating an IKE SA simply because one expired and was deleted actually solves a problem please describe the circumstances to me. Dan. From owner-ipsec@lists.tislabs.com Wed Dec 1 18:00:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA03120; Wed, 1 Dec 1999 18:00:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07149 Wed, 1 Dec 1999 19:54:03 -0500 (EST) Message-ID: <3845C2FE.A94E05D7@ire-ma.com> Date: Wed, 01 Dec 1999 19:53:19 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Tero Kivinen , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912020039.QAA10972@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here the scenario. Have some IPSec SAs between my laptop Client and some other site. IPSec SAs are alive, but IKE SAs all expired. I want to shut down my laptop and as a nice net-citizen I want to send IPSec SA DELETEs to the other end. If I follow your advice and do not send DELETEs - the other guy will keep these stale IPSec SAs for possibly another 8 hours (if he has no inactivity timeout, or no keep-alive going). No big deal, but not ideal either. Dan Harkins wrote: > On Wed, 01 Dec 1999 18:45:01 EST you wrote > > The question still remains - how to send DELETE notification when deleting IP > >Sec > > SA while there is no IKE SAs to that peer. > > No, the question is why do you have to send a DELETE notification when > deleting IPSec SAs and you have no IKE SAs to that peer. I don't think you do. > > > My vote - to re-key IKE SAs as soon as possible after they are expired or > > deleted (if there are active IPSec SAs with that peer) - so they will be arou > >nd > > when I need them, but if for some reason IKE SA cannot be re-keyed - do not s > >end > > IPSec SA DELETEs. Also, IMHO - deletion of IKE SA should be just that - no > > consequences for any IPSec SAs. > > I still think that the problem caused by not being able to send a DELETE > notification-- namely, a blackhole-- will only happen in edge conditions > and even then the problem will be readily noticible because it requires > manual intervention and the box on which the manual intervention is done > will start filling the event log with messages which should clue in any > cluefull operator that that command he just typed is doing something bad. > Further manual intervention will rectify the situation; problem solved. > In most cases the SAs will naturally be reestablished on their own and no > blackhole will happen. > > Re-establishing an IKE SA for the sole purpose of "so [it] will be around > when I need [it]" is not really a reason. It should be established if it > really is necessary like having to re-key the IPSec SAs to that peer. And > in that case you won't necessarily know that the IPSec SAs will need to > be reestablished when the IKE SA dies, you'll only know when the IPSec SAs > actually approach expiry. If they do need to be rekeyed an "establish SAs > with peer" message will be sent up to IKE who'll notice he has no phase 1 > SA with that peer and re-establish it then (and then satisfy the request > for IPSec SAs). If they don't need to be rekeyed then that is because they're > not being used and when they die a quiet death no one will notice. > > If negotiating an IKE SA simply because one expired and was deleted actually > solves a problem please describe the circumstances to me. > > Dan. From owner-ipsec@lists.tislabs.com Wed Dec 1 18:30:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06146; Wed, 1 Dec 1999 18:30:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07239 Wed, 1 Dec 1999 20:16:58 -0500 (EST) Message-Id: <199912020117.RAA11158@potassium.network-alchemy.com> To: Bronislav Kavsan cc: Tero Kivinen , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Wed, 01 Dec 1999 19:53:19 EST." <3845C2FE.A94E05D7@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11155.944097468.1@network-alchemy.com> Date: Wed, 01 Dec 1999 17:17:49 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But what if you do always keep up an IKE SA and you just suspend your laptop or pull the ethernet cable out and then do a shutdown? Now I've got the 2 IPSec SAs and an IKE SA. This problem isn't solvable. And it seems to be specific to mobile host implementations with short term SAs. Since IPSec, and IKE, are not mobile host-specific I don't think a general purpose rule to do this is necessarily needed. And, as you say, no big deal. I think a nice generic keep alive function would be more useful to implement. Why doesn't someone write a draft on this subject? Dan. On Wed, 01 Dec 1999 19:53:19 EST you wrote > Here the scenario. > > Have some IPSec SAs between my laptop Client and some other site. > IPSec SAs are alive, but IKE SAs all expired. > > I want to shut down my laptop and as a nice net-citizen I want to send IPSec >SA > DELETEs to the other end. > If I follow your advice and do not send DELETEs - the other guy will keep the >se > stale IPSec SAs for possibly another 8 hours (if he has no inactivity timeout >, or > no keep-alive going). No big deal, but not ideal either. > > Dan Harkins wrote: > > > On Wed, 01 Dec 1999 18:45:01 EST you wrote > > > The question still remains - how to send DELETE notification when deletin >g IP > > >Sec > > > SA while there is no IKE SAs to that peer. > > > > No, the question is why do you have to send a DELETE notification when > > deleting IPSec SAs and you have no IKE SAs to that peer. I don't think you >do. > > > > > My vote - to re-key IKE SAs as soon as possible after they are expired or > > > deleted (if there are active IPSec SAs with that peer) - so they will be >arou > > >nd > > > when I need them, but if for some reason IKE SA cannot be re-keyed - do n >ot s > > >end > > > IPSec SA DELETEs. Also, IMHO - deletion of IKE SA should be just that - n >o > > > consequences for any IPSec SAs. > > > > I still think that the problem caused by not being able to send a DELETE > > notification-- namely, a blackhole-- will only happen in edge conditions > > and even then the problem will be readily noticible because it requires > > manual intervention and the box on which the manual intervention is done > > will start filling the event log with messages which should clue in any > > cluefull operator that that command he just typed is doing something bad. > > Further manual intervention will rectify the situation; problem solved. > > In most cases the SAs will naturally be reestablished on their own and no > > blackhole will happen. > > > > Re-establishing an IKE SA for the sole purpose of "so [it] will be around > > when I need [it]" is not really a reason. It should be established if it > > really is necessary like having to re-key the IPSec SAs to that peer. And > > in that case you won't necessarily know that the IPSec SAs will need to > > be reestablished when the IKE SA dies, you'll only know when the IPSec SAs > > actually approach expiry. If they do need to be rekeyed an "establish SAs > > with peer" message will be sent up to IKE who'll notice he has no phase 1 > > SA with that peer and re-establish it then (and then satisfy the request > > for IPSec SAs). If they don't need to be rekeyed then that is because they' >re > > not being used and when they die a quiet death no one will notice. > > > > If negotiating an IKE SA simply because one expired and was deleted actuall >y > > solves a problem please describe the circumstances to me. > > > > Dan. > > From owner-ipsec@lists.tislabs.com Wed Dec 1 18:48:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07416; Wed, 1 Dec 1999 18:48:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07281 Wed, 1 Dec 1999 20:30:58 -0500 (EST) Message-ID: <3845CBB6.E22AFD7A@ire-ma.com> Date: Wed, 01 Dec 1999 20:30:33 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Tero Kivinen , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912020117.RAA11158@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree - non-graceful disconnect is not solvable without keep-alives, but I just wanted a clean disengagement under normal circumstances, which will be an overwhelming majority scenario. My guess about keep-alives is that people (incl. myself) are busy implementing proprietary keep-alive schemes and are reluctant to start a "keep-alive war" - it is not a simple subject as it seems. Also, some keep-alive schemes (.....) suggest sending keep-alives ONLY during actual IPSec traffic to ensure dial-up inactivity timeouts and subsequent auto-hang-up. This a good goal, but it doesn't solve the problem we discussing - absence of traffic will mean baseness of keep-alives and therefore stale IPSec SAs will remain undetected. Dan Harkins wrote: > But what if you do always keep up an IKE SA and you just suspend your > laptop or pull the ethernet cable out and then do a shutdown? Now I've got > the 2 IPSec SAs and an IKE SA. This problem isn't solvable. And it seems to > be specific to mobile host implementations with short term SAs. Since IPSec, > and IKE, are not mobile host-specific I don't think a general purpose rule > to do this is necessarily needed. And, as you say, no big deal. > > I think a nice generic keep alive function would be more useful to > implement. Why doesn't someone write a draft on this subject? > > Dan. > > On Wed, 01 Dec 1999 19:53:19 EST you wrote > > Here the scenario. > > > > Have some IPSec SAs between my laptop Client and some other site. > > IPSec SAs are alive, but IKE SAs all expired. > > > > I want to shut down my laptop and as a nice net-citizen I want to send IPSec > >SA > > DELETEs to the other end. > > If I follow your advice and do not send DELETEs - the other guy will keep the > >se > > stale IPSec SAs for possibly another 8 hours (if he has no inactivity timeout > >, or > > no keep-alive going). No big deal, but not ideal either. > > > > Dan Harkins wrote: > > > > > On Wed, 01 Dec 1999 18:45:01 EST you wrote > > > > The question still remains - how to send DELETE notification when deletin > >g IP > > > >Sec > > > > SA while there is no IKE SAs to that peer. > > > > > > No, the question is why do you have to send a DELETE notification when > > > deleting IPSec SAs and you have no IKE SAs to that peer. I don't think you > >do. > > > > > > > My vote - to re-key IKE SAs as soon as possible after they are expired or > > > > deleted (if there are active IPSec SAs with that peer) - so they will be > >arou > > > >nd > > > > when I need them, but if for some reason IKE SA cannot be re-keyed - do n > >ot s > > > >end > > > > IPSec SA DELETEs. Also, IMHO - deletion of IKE SA should be just that - n > >o > > > > consequences for any IPSec SAs. > > > > > > I still think that the problem caused by not being able to send a DELETE > > > notification-- namely, a blackhole-- will only happen in edge conditions > > > and even then the problem will be readily noticible because it requires > > > manual intervention and the box on which the manual intervention is done > > > will start filling the event log with messages which should clue in any > > > cluefull operator that that command he just typed is doing something bad. > > > Further manual intervention will rectify the situation; problem solved. > > > In most cases the SAs will naturally be reestablished on their own and no > > > blackhole will happen. > > > > > > Re-establishing an IKE SA for the sole purpose of "so [it] will be around > > > when I need [it]" is not really a reason. It should be established if it > > > really is necessary like having to re-key the IPSec SAs to that peer. And > > > in that case you won't necessarily know that the IPSec SAs will need to > > > be reestablished when the IKE SA dies, you'll only know when the IPSec SAs > > > actually approach expiry. If they do need to be rekeyed an "establish SAs > > > with peer" message will be sent up to IKE who'll notice he has no phase 1 > > > SA with that peer and re-establish it then (and then satisfy the request > > > for IPSec SAs). If they don't need to be rekeyed then that is because they' > >re > > > not being used and when they die a quiet death no one will notice. > > > > > > If negotiating an IKE SA simply because one expired and was deleted actuall > >y > > > solves a problem please describe the circumstances to me. > > > > > > Dan. > > > > From owner-ipsec@lists.tislabs.com Wed Dec 1 19:06:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08823; Wed, 1 Dec 1999 19:06:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07333 Wed, 1 Dec 1999 20:52:04 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 1 Dec 1999 17:55:04 -0800 (PST) From: Jan Vilhuber Reply-To: Jan Vilhuber To: Dan Harkins cc: ipsec@lists.tislabs.com Subject: keepalives (was Re: IPSec SA DELETE in "dangling" implementation) In-Reply-To: <199912020117.RAA11158@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 1 Dec 1999, Dan Harkins wrote: > I think a nice generic keep alive function would be more useful to > implement. Why doesn't someone write a draft on this subject? > I'm sort of working myself up to it, i.e. we're still wondering internally what's best. Problem I see is that there are several different scenarios where different types of keepalives will be necessary (i.e. a dial-up scenario has different requirements than a straight ethernet scenario; ethernet scenario will be more efficient and optimizable, but dial-up is not). Once I get something written up, I'll post it to the list, but I have my doubts that we'll come up with a single sanctioned mechanism. There'll likely be at least two. It's possible we can come up with one generic enough to be used in both cases, but I doubt it (I'm a pessimist). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 1 19:12:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09212; Wed, 1 Dec 1999 19:11:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07359 Wed, 1 Dec 1999 20:58:22 -0500 (EST) Message-Id: <199912020158.RAA11355@potassium.network-alchemy.com> To: Bronislav Kavsan cc: Tero Kivinen , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Wed, 01 Dec 1999 20:30:33 EST." <3845CBB6.E22AFD7A@ire-ma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11352.944099936.1@network-alchemy.com> Date: Wed, 01 Dec 1999 17:58:56 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 01 Dec 1999 20:30:33 EST you wrote > My guess about keep-alives is that people (incl. myself) are busy implementin >g > proprietary keep-alive schemes and are reluctant to start a "keep-alive war" >- it > is not a simple subject as it seems. If people are happy with proprietary schemes-- meaning that they'll only "clean-up" if they speak to themselves-- then this problem must not be important enough for this working group to consider. Dan. From owner-ipsec@lists.tislabs.com Wed Dec 1 19:27:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10121; Wed, 1 Dec 1999 19:27:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07406 Wed, 1 Dec 1999 21:19:47 -0500 (EST) Message-ID: <3845D728.FBFE5939@ire-ma.com> Date: Wed, 01 Dec 1999 21:19:21 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Tero Kivinen , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912020158.RAA11355@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just for starters (as an example of possible keep-alive implementation difficulties) - keep-alive in relationship to "continuous" IKE SAs - if we want to use protected NOTIFYs (ack-ed or not) for keep-alives - we will run into the same issue of doing it in "dangling" implementations. So - it could be a catch22 situation - we need keep-alives to be able to detect inactive IPSec SAs (because we may not be able to send DELETEs without IKE SA), but we need "continouos" IKE SAs to run protected keep-alives. Hmmm....... Dan Harkins wrote: > On Wed, 01 Dec 1999 20:30:33 EST you wrote > > My guess about keep-alives is that people (incl. myself) are busy implementin > >g > > proprietary keep-alive schemes and are reluctant to start a "keep-alive war" > >- it > > is not a simple subject as it seems. > > If people are happy with proprietary schemes-- meaning that they'll only > "clean-up" if they speak to themselves-- then this problem must not be > important enough for this working group to consider. > > Dan. From owner-ipsec@lists.tislabs.com Thu Dec 2 07:53:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA01128; Thu, 2 Dec 1999 07:53:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09110 Thu, 2 Dec 1999 08:58:21 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD59AB@exchange> From: Andrew Krywaniuk To: Tero Kivinen , Bronislav Kavsan Cc: Paul Hoffman , ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Thu, 2 Dec 1999 09:04:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If there is no traffic going on the SA then there is no need to rekey > it. This also means that the IPsec SA can only expire because of the > seconds limit. This means that the other end has the same lifetime > information, thus it is going to expire it at the same time. No > problem there. I don't think it's fair to assume the other end has the same lifetime information. Sending lifetime notifies isn't required and parsing them (and obeying them) is not a MUST. If YOU continue to send traffic on an SA that I have expired, that would still be a violation of MY security policy. In order to force the other side to cooperate, we have to send the deletes (unless parsing and obeying lifetime notifies is required). The point here is that if I want to be sure that my security policy is enforced then I must send the delete. If I hang up without sending the delete then it's my own fault (I am defeating my own security policy). And just as an afterthought: if anyone did want to attempt to hijack your session undetected, after you've hung up would be the best time. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Dec 2 08:12:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01433; Thu, 2 Dec 1999 08:12:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09128 Thu, 2 Dec 1999 09:03:43 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD59B4@exchange> From: Tim Jenkins To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Heartbeats (was RE: keepalives) Date: Thu, 2 Dec 1999 09:09:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a nit, but if we really mean heartbeat, can we call it that? A keep-alive to me is something that defeats the peer's inactivity time-out detection mechanism, while a heartbeat is something that helps detect the health of the peer. And a heartbeat shouldn't defeat inactivity detection, either. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: December 1, 1999 8:55 PM > To: Dan Harkins > Cc: ipsec@lists.tislabs.com > Subject: keepalives (was Re: IPSec SA DELETE in "dangling" > implementation) > > > On Wed, 1 Dec 1999, Dan Harkins wrote: > > I think a nice generic keep alive function would be more useful to > > implement. Why doesn't someone write a draft on this subject? > > > I'm sort of working myself up to it, i.e. we're still > wondering internally > what's best. > > Problem I see is that there are several different scenarios > where different > types of keepalives will be necessary (i.e. a dial-up > scenario has different > requirements than a straight ethernet scenario; ethernet > scenario will be > more efficient and optimizable, but dial-up is not). Once I > get something > written up, I'll post it to the list, but I have my doubts > that we'll come up > with a single sanctioned mechanism. There'll likely be at > least two. It's > possible we can come up with one generic enough to be used in > both cases, but > I doubt it (I'm a pessimist). > > jan > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Thu Dec 2 10:11:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03089; Thu, 2 Dec 1999 10:11:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09717 Thu, 2 Dec 1999 11:14:30 -0500 (EST) Date: Thu, 2 Dec 1999 18:17:52 +0200 (EET) Message-Id: <199912021617.SAA16897@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Andrew Krywaniuk Cc: Bronislav Kavsan , Paul Hoffman , ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFD59AB@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFFD59AB@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 11 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > > If there is no traffic going on the SA then there is no need to rekey > > it. This also means that the IPsec SA can only expire because of the > > seconds limit. This means that the other end has the same lifetime > > information, thus it is going to expire it at the same time. No > > problem there. > > I don't think it's fair to assume the other end has the same lifetime > information. Sending lifetime notifies isn't required and parsing them (and > obeying them) is not a MUST. If I am a initiator and said, that I am going to use this lifetime, and the other end does not trust me, it is his problem. If I am a responder and I send responder lifetime notification, and he doesn't trust that either, that is again his problem. It is not a MUST to trust delete payloads either. The ISAKMP RFC says that you are allowed to ignore the delete payloads, they are only sent to inform you that the other end deleted his SA. You don't need to act based on that information if you dont like. If the other ends implementation is broken, I really don't care if he keeps few extra SAs up and running for too long. > If YOU continue to send traffic on an SA that I have expired, that would > still be a violation of MY security policy. In order to force the other side > to cooperate, we have to send the deletes (unless parsing and obeying > lifetime notifies is required). Even if you send delete payloads, that does NOT mean that the other end still cannot send you packets. It is allowed in the RFC to keep sending packets using the old SPI. Sending delete means that you are saying to the other end that IF they still continue sending packets to you using that SPI, you will drop them. There is NO way to force the other end not to cooperate. > The point here is that if I want to be sure that my security policy is > enforced then I must send the delete. If I hang up without sending the > delete then it's my own fault (I am defeating my own security policy). If the other end ignores all the delete payloads (as it is allowed to do), how that is going to enforce your policy? > And just as an afterthought: if anyone did want to attempt to hijack your > session undetected, after you've hung up would be the best time. If somebody is able to hijack my session, he would also be able to read everything I sent using that session. I do not plan to use that weak security parameters to allow that. We are supposed to make the even the reading of the material almost impossible and doing real time breaking of the IPsec should be much harder. Anyways sending deletes does not help here at all, because the attacker can simply delete those packets (or respond to them if he broke the Diffie-Hellman). Anyways I don't think that is very valid point. You MUST set your lifetime low enough, so it will remove this kind of possiblity. Whether or not you send delete payloads changes that thing. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 2 10:42:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03468; Thu, 2 Dec 1999 10:42:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09910 Thu, 2 Dec 1999 11:56:34 -0500 (EST) Message-ID: <3846A583.A8766750@redcreek.com> Date: Thu, 02 Dec 1999 08:59:47 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912020117.RAA11158@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > But what if you do always keep up an IKE SA and you just suspend your > laptop or pull the ethernet cable out and then do a shutdown? Now I've got > the 2 IPSec SAs and an IKE SA. This problem isn't solvable. And it seems to > be specific to mobile host implementations with short term SAs. Since IPSec, > and IKE, are not mobile host-specific I don't think a general purpose rule > to do this is necessarily needed. And, as you say, no big deal. > > I think a nice generic keep alive function would be more useful to > implement. Why doesn't someone write a draft on this subject? > > Dan. > This is just a hypothetical question: If we did have a keep-alive protocol, would there remain any value in sending DELETEs at all? -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Thu Dec 2 10:43:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03492; Thu, 2 Dec 1999 10:43:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09938 Thu, 2 Dec 1999 12:01:15 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5AFD@exchange> From: Andrew Krywaniuk To: Tero Kivinen , Andrew Krywaniuk Cc: Bronislav Kavsan , Paul Hoffman , ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Thu, 2 Dec 1999 12:07:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sure, the other side can ignore the delete, but will they? How many implementations out there ignore deletes? How many implementations out there ignore or do not send lifetime notifies? IPSec relies on a restricted kind of trust. If I communicate with you encrypted then I trust you not to be malicious (e.g. not to reveal my confidential data to outsiders); otherwise, my policy with you would be BLOCK. However, I don't trust you enough to choose the security parameters for the session. You would presumably refuse to communicate with me if I chose "ESP Rot13 AH Checksum". That's why the security parameters are negotiated. However, the SA lifetime is not negotiated in the same way, even though it is a legitimate aspect of that policy. If I set my SA lifetime to 5 minutes/100 kb and you set yours to forever (or some other large value) then you are violating my security policy, even if you are not doing it maliciously. As I said, I trust you not to be malicious, which is why I don't think you would ignore the delete if you were able to understand it. My comment on session hijacking was, as I said, an afterthought. I merely pointed out that if someone wanted to attempt to hijack your session then after you've hung up is the perfect time to do it, as you're no longer around to detect the spoofed packets and the possible error notifies. If you restrict your SA lifetime to 5 minutes/100 kb, it is presumably because you believe that there is some finite risk of an intruder cracking the SA if it lasts longer or carries more data than that. If the peer continues to obliviously transfer data on that SA longer than that then you run the risk of an attack. I'm just saying that you're supposed to trust the peer not to be malicious, but you're not supposed to trust them to make sensible policy decisions. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Thursday, December 02, 1999 11:18 AM > To: Andrew Krywaniuk > Cc: Bronislav Kavsan; Paul Hoffman; ipsec@lists.tislabs.com > Subject: RE: IPSec SA DELETE in "dangling" implementation > > > Andrew Krywaniuk writes: > > > If there is no traffic going on the SA then there is no > need to rekey > > > it. This also means that the IPsec SA can only expire > because of the > > > seconds limit. This means that the other end has the same lifetime > > > information, thus it is going to expire it at the same time. No > > > problem there. > > > > I don't think it's fair to assume the other end has the > same lifetime > > information. Sending lifetime notifies isn't required and > parsing them (and > > obeying them) is not a MUST. > > If I am a initiator and said, that I am going to use this lifetime, > and the other end does not trust me, it is his problem. If I am a > responder and I send responder lifetime notification, and he doesn't > trust that either, that is again his problem. > > It is not a MUST to trust delete payloads either. The ISAKMP RFC says > that you are allowed to ignore the delete payloads, they are only sent > to inform you that the other end deleted his SA. You don't need to act > based on that information if you dont like. > > If the other ends implementation is broken, I really don't care if he > keeps few extra SAs up and running for too long. > > > If YOU continue to send traffic on an SA that I have > expired, that would > > still be a violation of MY security policy. In order to > force the other side > > to cooperate, we have to send the deletes (unless parsing > and obeying > > lifetime notifies is required). > > Even if you send delete payloads, that does NOT mean that the other > end still cannot send you packets. It is allowed in the RFC to keep > sending packets using the old SPI. Sending delete means that you are > saying to the other end that IF they still continue sending packets to > you using that SPI, you will drop them. > > There is NO way to force the other end not to cooperate. > > > The point here is that if I want to be sure that my > security policy is > > enforced then I must send the delete. If I hang up without > sending the > > delete then it's my own fault (I am defeating my own > security policy). > > If the other end ignores all the delete payloads (as it is allowed to > do), how that is going to enforce your policy? > > > And just as an afterthought: if anyone did want to attempt > to hijack your > > session undetected, after you've hung up would be the best time. > > If somebody is able to hijack my session, he would also be able to > read everything I sent using that session. I do not plan to use that > weak security parameters to allow that. We are supposed to make the > even the reading of the material almost impossible and doing real time > breaking of the IPsec should be much harder. > > Anyways sending deletes does not help here at all, because the > attacker can simply delete those packets (or respond to them if he > broke the Diffie-Hellman). > > Anyways I don't think that is very valid point. You MUST set your > lifetime low enough, so it will remove this kind of possiblity. > Whether or not you send delete payloads changes that thing. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Thu Dec 2 11:04:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03735; Thu, 2 Dec 1999 11:04:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10091 Thu, 2 Dec 1999 12:31:39 -0500 (EST) Date: Thu, 2 Dec 1999 12:33:29 -0500 (EST) From: Henry Spencer To: Tim Jenkins cc: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFD59B4@exchange> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Tim Jenkins wrote: > Just a nit, but if we really mean heartbeat, can we call it that? > A keep-alive to me is something that defeats the peer's inactivity time-out > detection mechanism, while a heartbeat is something that helps detect the > health of the peer... Unfortunately, the term "keep-alive" is already well established in this connection in the TCP/IP world. (See, for example, section 4.2.3.6 of RFC 1122.) Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Dec 2 11:18:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03925; Thu, 2 Dec 1999 11:18:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10136 Thu, 2 Dec 1999 12:40:17 -0500 (EST) Message-ID: <3846AF70.88633DEC@ire-ma.com> Date: Thu, 02 Dec 1999 12:42:08 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ricky Charlet CC: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912020117.RAA11158@potassium.network-alchemy.com> <3846A583.A8766750@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes - there is value of sending DELETEs in these situations - because (as Tim Jenkins said) the hearbeats will only be used if there is actual IPSec traffic to let inactivity timeouts and auto-dial-hangup to work. But in LAN situations or when there is no inactivity timeouts implemented - IPSec SA will remain stale for a long time - and it would be nice to send DELETE to the peer when I am shutting down my laptop. Ricky Charlet wrote: > Dan Harkins wrote: > > > > But what if you do always keep up an IKE SA and you just suspend your > > laptop or pull the ethernet cable out and then do a shutdown? Now I've got > > the 2 IPSec SAs and an IKE SA. This problem isn't solvable. And it seems to > > be specific to mobile host implementations with short term SAs. Since IPSec, > > and IKE, are not mobile host-specific I don't think a general purpose rule > > to do this is necessarily needed. And, as you say, no big deal. > > > > I think a nice generic keep alive function would be more useful to > > implement. Why doesn't someone write a draft on this subject? > > > > Dan. > > > > This is just a hypothetical question: If we did have a keep-alive > protocol, would there remain any value in sending DELETEs at all? > > -- > #################################### > # Ricky Charlet > # (510) 795-6903 > # rcharlet@redcreek.com > #################################### > > end Howdy; -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Thu Dec 2 11:28:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04019; Thu, 2 Dec 1999 11:27:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10114 Thu, 2 Dec 1999 12:38:27 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5B37@exchange> From: Tim Jenkins To: Henry Spencer Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Thu, 2 Dec 1999 12:44:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: December 2, 1999 12:33 PM > To: Tim Jenkins > Cc: Jan Vilhuber; ipsec@lists.tislabs.com > Subject: Re: Heartbeats (was RE: keepalives) > > > On Thu, 2 Dec 1999, Tim Jenkins wrote: > > Just a nit, but if we really mean heartbeat, can we call it that? > > A keep-alive to me is something that defeats the peer's > inactivity time-out > > detection mechanism, while a heartbeat is something that > helps detect the > > health of the peer... > > Unfortunately, the term "keep-alive" is already well > established in this > connection in the TCP/IP world. (See, for example, section 4.2.3.6 of > RFC 1122.) Okay, so we perpetuate a confusing term. What should we call a keep-alive as I've defined above? Or does no one care? From owner-ipsec@lists.tislabs.com Thu Dec 2 11:30:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04088; Thu, 2 Dec 1999 11:30:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10227 Thu, 2 Dec 1999 13:01:18 -0500 (EST) Message-ID: <3846B59D.553255E3@ibondinc.com> Date: Thu, 02 Dec 1999 10:08:31 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Tylor Allison CC: ipsec@lists.tislabs.com, carney@securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Tylor Allison wrote: > I have a question that I hope some of you out there can help me answer. > The scenario is this: Say I have a host machine using IKE/IPSEC which has > multiple aliases for the same interface (or multiple interfaces routable > to the same remote peer). When I start a IKE negotiation to the remote peer > the IKE implementation does not have control over which interface address > gets inserted in the UDP packet. If I wish to use an IPV4 address in the > identity payload, my IKE implementation will choose the IPV4 address to use > in the ID payload based on the IKE implementations configured policy. > > My question is, what happens if the IPV4 address selected in the ID payload > does not match the actual source address contained in the packet? I know for > the pre-shared key case, this won't (or shouldn't) work (at least for Phase > 1 using Main Mode), since the actual remote address used to send the packet > is used to determine the pre-shared key used to authenticate the session. > But how should this be handled for signature based authentication? If the > IPV4 address specified in the identity payload matches the IP address in > the subjectAltName extension of the cert used for sig authentication and > this matches the IKE local policy, does it need to match the actual > address received from the packet? > > And what if there is no ip address in the subject-alt name? Is it then > a requirement that the actual gateway match the IPV4_ADDR identity? > > How would implementations out there handle this scenario? Has anyone > else thought of how to handle multiple interface aliases so that ISAKMP > does "the right thing". This problem can be solved if you use identification other than IP address, in case of signature authentication mode. In case of preshared key authentication, while configuring the IKE policy, one should know the source IP adress and inform other end. > > > Thanks in advance. > > --- > Tylor Allison tylor_allison@securecomputing.com > Secure Computing Corporation Regards Srini From owner-ipsec@lists.tislabs.com Thu Dec 2 11:49:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04254; Thu, 2 Dec 1999 11:49:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10333 Thu, 2 Dec 1999 13:18:00 -0500 (EST) Message-ID: <3846B93C.F0216F51@ibondinc.com> Date: Thu, 02 Dec 1999 10:23:58 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: Tero Kivinen , Bronislav Kavsan , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <319A1C5F94C8D11192DE00805FBBADDFFD59AB@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > If there is no traffic going on the SA then there is no need to rekey > > it. This also means that the IPsec SA can only expire because of the > > seconds limit. This means that the other end has the same lifetime > > information, thus it is going to expire it at the same time. No > > problem there. > > I don't think it's fair to assume the other end has the same lifetime > information. Sending lifetime notifies isn't required and parsing them (and > obeying them) is not a MUST. > > If YOU continue to send traffic on an SA that I have expired, that would > still be a violation of MY security policy. In order to force the other side > to cooperate, we have to send the deletes (unless parsing and obeying > lifetime notifies is required). > > The point here is that if I want to be sure that my security policy is > enforced then I must send the delete. If I hang up without sending the > delete then it's my own fault (I am defeating my own security policy). > > Since life times may not be same on both ends, I also feel that we need to send Deletes to other end when IPSEC SA hard life time expires. But, there is a possibility that 'deletes' may get lost or IKE negotiation may not succeed. To recover from this, implementation can have inactivity apart from life time as suggested in the mailing list a while ago. Inactivity calculation start whenever any packet is sent using outbound SA. If no packet comes back on corresponding inbound SA for inactivity time period, then flush both outbound and inbound SA. Regards Srini From owner-ipsec@lists.tislabs.com Thu Dec 2 11:57:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04352; Thu, 2 Dec 1999 11:57:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10357 Thu, 2 Dec 1999 13:22:25 -0500 (EST) Message-Id: <199912021824.MAA05280@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Srinivasa Rao Addepalli cc: Tylor Allison , ipsec@lists.tislabs.com, carney@securecomputing.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-reply-to: Your message of "Thu, 02 Dec 1999 10:08:31 PST." <3846B59D.553255E3@ibondinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Dec 1999 12:24:40 -0600 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hi, > > Tylor Allison wrote: > > > I have a question that I hope some of you out there can help me answer. > > The scenario is this: Say I have a host machine using IKE/IPSEC which has > > multiple aliases for the same interface (or multiple interfaces routable > > to the same remote peer). When I start a IKE negotiation to the remote peer > > the IKE implementation does not have control over which interface address > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the > > identity payload, my IKE implementation will choose the IPV4 address to use > > in the ID payload based on the IKE implementations configured policy. > > > > My question is, what happens if the IPV4 address selected in the ID payload > > does not match the actual source address contained in the packet? > > I know for > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase > > 1 using Main Mode), since the actual remote address used to send the packet > > is used to determine the pre-shared key used to authenticate the session. This is the question at hand ... > > But how should this be handled for signature based authentication? If the > > IPV4 address specified in the identity payload matches the IP address in > > the subjectAltName extension of the cert used for sig authentication and > > this matches the IKE local policy, does it need to match the actual > > address received from the packet? Any suggestions? > > > > And what if there is no ip address in the subject-alt name? Is it then > > a requirement that the actual gateway match the IPV4_ADDR identity? > > > > How would implementations out there handle this scenario? Has anyone > > else thought of how to handle multiple interface aliases so that ISAKMP > > does "the right thing". > > This problem can be solved if you use identification other than > IP address, in case of signature authentication mode. No fair changing the problem to one that is easier to solve :) > > In case of preshared key authentication, while configuring the > IKE policy, one should know the source IP adress and inform > other end. > Who should know the source IP address? Consider the case of a box with multiple network interface cards and perhaps aliased IP address on some of those interfaces. The route to the remote peer is what determines the interface used to send the UDP packets that are sent by ISAKMP. The OS uses some heuristic to determine the aliase IP that is used to set the source address of packets from a given interface. Both the route and aliase choice are subject to change. I admit this is somewhat of a rare case as most VPN gateways have but a single IP address for all of the VPN traffic. But in our implementation it is a situation we must consider. Regards, Michael Carney > > > > > > Thanks in advance. > > > > --- > > Tylor Allison tylor_allison@securecomputing.com > > Secure Computing Corporation > > Regards > Srini > > From owner-ipsec@lists.tislabs.com Thu Dec 2 12:11:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04523; Thu, 2 Dec 1999 12:11:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10397 Thu, 2 Dec 1999 13:35:29 -0500 (EST) Message-ID: <3846BD8E.A38E736A@ibondinc.com> Date: Thu, 02 Dec 1999 10:42:23 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Mike Carney CC: Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: <199912021824.MAA05280@jumpsrv.stp.securecomputing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike Carney wrote: > > Hi, > > > > Tylor Allison wrote: > > > > > I have a question that I hope some of you out there can help me answer. > > > The scenario is this: Say I have a host machine using IKE/IPSEC which has > > > multiple aliases for the same interface (or multiple interfaces routable > > > to the same remote peer). When I start a IKE negotiation to the remote peer > > > the IKE implementation does not have control over which interface address > > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the > > > identity payload, my IKE implementation will choose the IPV4 address to use > > > in the ID payload based on the IKE implementations configured policy. > > > > > > My question is, what happens if the IPV4 address selected in the ID payload > > > does not match the actual source address contained in the packet? > > > I know for > > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase > > > 1 using Main Mode), since the actual remote address used to send the packet > > > is used to determine the pre-shared key used to authenticate the session. > > This is the question at hand ... > > > > But how should this be handled for signature based authentication? If the > > > IPV4 address specified in the identity payload matches the IP address in > > > the subjectAltName extension of the cert used for sig authentication and > > > this matches the IKE local policy, does it need to match the actual > > > address received from the packet? > > Any suggestions? > > > > > > > And what if there is no ip address in the subject-alt name? Is it then > > > a requirement that the actual gateway match the IPV4_ADDR identity? > > > > > > How would implementations out there handle this scenario? Has anyone > > > else thought of how to handle multiple interface aliases so that ISAKMP > > > does "the right thing". > > > > This problem can be solved if you use identification other than > > IP address, in case of signature authentication mode. > > No fair changing the problem to one that is easier to solve :) > > > > > In case of preshared key authentication, while configuring the > > IKE policy, one should know the source IP adress and inform > > other end. > > > > Who should know the source IP address? > > Consider the case of a box with multiple network interface cards and > perhaps aliased IP address on some of those interfaces. The route to > the remote peer is what determines the interface used to send the UDP packets > that are sent by ISAKMP. The OS uses some heuristic to determine the > aliase IP that is used to set the source address of packets from a > given interface. > > Both the route and aliase choice are subject to change. > > I admit this is somewhat of a rare case as most VPN gateways > have but a single IP address for all of the VPN traffic. But in > our implementation it is a situation we must consider. I agree that this situation certainly happens, that is the reason why we use signature authentication in these cases so that other end need not know your gateway IP address. You can still use preshared authentication, but only aggressive mode is possible ( This is similar to remote access cases where the IP address is not known ). I understand this is some sort work around. I also would like to hear other people comments on this subject. Regards Srini > > > Regards, > Michael Carney > > > > > > > > > > Thanks in advance. > > > > > > --- > > > Tylor Allison tylor_allison@securecomputing.com > > > Secure Computing Corporation > > > > Regards > > Srini > > > > From owner-ipsec@lists.tislabs.com Thu Dec 2 12:15:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04575; Thu, 2 Dec 1999 12:15:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10410 Thu, 2 Dec 1999 13:37:06 -0500 (EST) Message-ID: <06db01bf3cf0$ef854750$9106b0d0@corp.certifiedtime.com> From: "todd.glassey" To: "Tim Jenkins" Cc: References: <319A1C5F94C8D11192DE00805FBBADDFFD59B4@exchange> Subject: Re: Heartbeats (was RE: keepalives) Date: Thu, 2 Dec 1999 10:13:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim, FYI - We use the term "heartbeat" in STime WG as a reference for the local frequency source in the Host's timebase service model. One of the things we are working on is secure timebase Steering vs. Jam Setting (ie. the maintaining of the clock accurately without violating the "boundaries of the timebase's granularity" relative to UTC). This requires both a fixed reference point for the HOST Synchronization event and the operations of the local oscillator and timebase BIOS service infrastructure. I would rather see the term Keep-Alive used to refer to the process of keeping the channel open and the session maintained, myself. Todd Glassey ----- Original Message ----- From: "Tim Jenkins" To: "Jan Vilhuber" Cc: Sent: Thursday, December 02, 1999 06:09 AM Subject: Heartbeats (was RE: keepalives) > Just a nit, but if we really mean heartbeat, can we call it that? > > A keep-alive to me is something that defeats the peer's inactivity time-out > detection mechanism, while a heartbeat is something that helps detect the > health of the peer. And a heartbeat shouldn't defeat inactivity detection, > either. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: December 1, 1999 8:55 PM > > To: Dan Harkins > > Cc: ipsec@lists.tislabs.com > > Subject: keepalives (was Re: IPSec SA DELETE in "dangling" > > implementation) > > > > > > On Wed, 1 Dec 1999, Dan Harkins wrote: > > > I think a nice generic keep alive function would be more useful to > > > implement. Why doesn't someone write a draft on this subject? > > > > > I'm sort of working myself up to it, i.e. we're still > > wondering internally > > what's best. > > > > Problem I see is that there are several different scenarios > > where different > > types of keepalives will be necessary (i.e. a dial-up > > scenario has different > > requirements than a straight ethernet scenario; ethernet > > scenario will be > > more efficient and optimizable, but dial-up is not). Once I > > get something > > written up, I'll post it to the list, but I have my doubts > > that we'll come up > > with a single sanctioned mechanism. There'll likely be at > > least two. It's > > possible we can come up with one generic enough to be used in > > both cases, but > > I doubt it (I'm a pessimist). > > > > jan > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > From owner-ipsec@lists.tislabs.com Thu Dec 2 13:00:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05183; Thu, 2 Dec 1999 13:00:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10722 Thu, 2 Dec 1999 14:33:43 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 11:36:38 -0800 (PST) From: Jan Vilhuber To: Mike Carney cc: Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <199912021824.MAA05280@jumpsrv.stp.securecomputing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A more interesting question, perhaps, and one we've been struggling with as well, is: If you ignore the ID_IPV4 payload altogether, pick your key based on the source-ip-address (which may be different than the IPV4 ID!), does this open a security hole? I would argue that it doesn't and that you can safely ignore the ID payload in the MM/pre-shared scenario, since it adds no value anyway. Donning flame-proof suit, jan On Thu, 2 Dec 1999, Mike Carney wrote: > > Hi, > > > > Tylor Allison wrote: > > > > > I have a question that I hope some of you out there can help me answer. > > > The scenario is this: Say I have a host machine using IKE/IPSEC which has > > > multiple aliases for the same interface (or multiple interfaces routable > > > to the same remote peer). When I start a IKE negotiation to the remote peer > > > the IKE implementation does not have control over which interface address > > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the > > > identity payload, my IKE implementation will choose the IPV4 address to use > > > in the ID payload based on the IKE implementations configured policy. > > > > > > My question is, what happens if the IPV4 address selected in the ID payload > > > does not match the actual source address contained in the packet? > > > I know for > > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase > > > 1 using Main Mode), since the actual remote address used to send the packet > > > is used to determine the pre-shared key used to authenticate the session. > > This is the question at hand ... > > > > But how should this be handled for signature based authentication? If the > > > IPV4 address specified in the identity payload matches the IP address in > > > the subjectAltName extension of the cert used for sig authentication and > > > this matches the IKE local policy, does it need to match the actual > > > address received from the packet? > > Any suggestions? > > > > > > > And what if there is no ip address in the subject-alt name? Is it then > > > a requirement that the actual gateway match the IPV4_ADDR identity? > > > > > > How would implementations out there handle this scenario? Has anyone > > > else thought of how to handle multiple interface aliases so that ISAKMP > > > does "the right thing". > > > > This problem can be solved if you use identification other than > > IP address, in case of signature authentication mode. > > No fair changing the problem to one that is easier to solve :) > > > > > In case of preshared key authentication, while configuring the > > IKE policy, one should know the source IP adress and inform > > other end. > > > > Who should know the source IP address? > > Consider the case of a box with multiple network interface cards and > perhaps aliased IP address on some of those interfaces. The route to > the remote peer is what determines the interface used to send the UDP packets > that are sent by ISAKMP. The OS uses some heuristic to determine the > aliase IP that is used to set the source address of packets from a > given interface. > > Both the route and aliase choice are subject to change. > > I admit this is somewhat of a rare case as most VPN gateways > have but a single IP address for all of the VPN traffic. But in > our implementation it is a situation we must consider. > > Regards, > Michael Carney > > > > > > > > > > > Thanks in advance. > > > > > > --- > > > Tylor Allison tylor_allison@securecomputing.com > > > Secure Computing Corporation > > > > Regards > > Srini > > > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 13:07:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05242; Thu, 2 Dec 1999 13:07:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10764 Thu, 2 Dec 1999 14:44:04 -0500 (EST) Message-Id: <199912021944.LAA13764@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: Tero Kivinen , Bronislav Kavsan , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Thu, 02 Dec 1999 12:07:23 EST." <319A1C5F94C8D11192DE00805FBBADDFFD5AFD@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13761.944163870.1@network-alchemy.com> Date: Thu, 02 Dec 1999 11:44:30 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 02 Dec 1999 12:07:23 EST you wrote > However, the SA lifetime is not negotiated in the same way, even though it > is a legitimate aspect of that policy. If I set my SA lifetime to 5 > minutes/100 kb and you set yours to forever (or some other large value) then > you are violating my security policy, even if you are not doing it > maliciously. As I said, I trust you not to be malicious, which is why I > don't think you would ignore the delete if you were able to understand it. Aside from programmer laziness why would someone not respect the negotiated lifetime (if the offer is less than the configured lifetime) and use the responder-lifetime notify (if the offer was more)? Is this the reason for the rekeying problems that people have? Granted support for the responder-lifetime notify is optional but it's much easier to implement that The Rekeying Draft! If people are worried about being nice net citizens then use the responder- lifetime notify. It's very nice. Dan. From owner-ipsec@lists.tislabs.com Thu Dec 2 13:27:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05464; Thu, 2 Dec 1999 13:27:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10798 Thu, 2 Dec 1999 15:00:41 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5C1A@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Thu, 2 Dec 1999 15:05:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: December 2, 1999 2:45 PM > To: Andrew Krywaniuk > Cc: Tero Kivinen; Bronislav Kavsan; Paul Hoffman; > ipsec@lists.tislabs.com > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > On Thu, 02 Dec 1999 12:07:23 EST you wrote > > However, the SA lifetime is not negotiated in the same way, > even though it > > is a legitimate aspect of that policy. If I set my SA lifetime to 5 > > minutes/100 kb and you set yours to forever (or some other > large value) then > > you are violating my security policy, even if you are not doing it > > maliciously. As I said, I trust you not to be malicious, > which is why I > > don't think you would ignore the delete if you were able to > understand it. > > Aside from programmer laziness why would someone not respect > the negotiated > lifetime (if the offer is less than the configured lifetime) > and use the > responder-lifetime notify (if the offer was more)? Is this > the reason for the > rekeying problems that people have? Granted support for the > responder-lifetime > notify is optional but it's much easier to implement that The > Rekeying Draft! > Dan, I think you're missing the point of the re-keying draft (the phase 2 part, I mean). The re-keying draft suggests how to move your traffic to the new SA from the old SA. The lifetime setting stuff can be used to determine who initiates and when the re-keying is done. That's a different problem than dealt with by the draft. The only thing the draft intends to suggest about that is that you try avoid simultaneous re-keying in both directions. And you're right, if everyone used the responder lifetime notification, a simple rule could have been that only the initiator initiates re-keys. But we're not there, and once again, that's not the point of the draft. > If people are worried about being nice net citizens then use > the responder- > lifetime notify. It's very nice. I agree 100% that it's very nice. But the reality is that it is optional, so you cannot know 100% of the time that the peer supports it. So, if someone wants to be a nice net citizen, why would they say "screw you if you don't use the responder lifetime notify"? > > Dan. > Tim From owner-ipsec@lists.tislabs.com Thu Dec 2 13:33:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05572; Thu, 2 Dec 1999 13:33:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10828 Thu, 2 Dec 1999 15:13:41 -0500 (EST) Message-Id: <199912022015.MAA13876@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Thu, 02 Dec 1999 15:05:39 EST." <319A1C5F94C8D11192DE00805FBBADDFFD5C1A@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13873.944165706.1@network-alchemy.com> Date: Thu, 02 Dec 1999 12:15:06 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 02 Dec 1999 15:05:39 EST you wrote > > The lifetime setting stuff can be used to determine who > initiates and when the re-keying is done. That's a > different problem than dealt with by the draft. The > only thing the draft intends to suggest about that is > that you try avoid simultaneous re-keying in both > directions. And you're right, if everyone used the > responder lifetime notification, a simple rule > could have been that only the initiator initiates re-keys. But that rule is unnecessary. Just rekey at X% of the lifetime with some jitter. I may make X=98 and you may make X=97 or whatever it doesn't matter. And if you talk to your own box then even if you both have identical values of X the jitter will make simultaneous rekey very unlikely. And even if it happens, so what? > > If people are worried about being nice net citizens then use > > the responder- > > lifetime notify. It's very nice. > > I agree 100% that it's very nice. But the reality is that > it is optional, so you cannot know 100% of the time that > the peer supports it. So, if someone wants to be a nice > net citizen, why would they say "screw you if you don't > use the responder lifetime notify"? But as Kivinen pointed out, deletes are optional too. And I'm not advocating saying "screw you" I'm saying that your problems will go away if you just Do The Right Thing. Yes, doing the right thing is optional but if you don't you have problems that require a whole bunch of extra work to fix (and causes other work which requires more fixing) and some of this work is based on other optional features being implemented too. I'll ask again: why wouldn't anyone use the responder-lifetime notify for lifetimes which are greater than the configured value and respect the lifetimes of offers which are less than the configured value? Dan. From owner-ipsec@lists.tislabs.com Thu Dec 2 13:45:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05729; Thu, 2 Dec 1999 13:45:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10890 Thu, 2 Dec 1999 15:30:39 -0500 (EST) Date: Thu, 2 Dec 1999 22:33:56 +0200 (EET) From: Markku Savela Message-Id: <199912022033.WAA15645@anise.tte.vtt.fi> To: srao@ibondinc.com CC: ipsec@lists.tislabs.com In-reply-to: <3846B93C.F0216F51@ibondinc.com> (message from Srinivasa Rao Addepalli on Thu, 02 Dec 1999 10:23:58 -0800) Subject: Re: IPSec SA DELETE in "dangling" implementation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Since life times may not be same on both ends, I also feel that we need > to send Deletes to other end when IPSEC SA hard life time expires. I claim: An IPSEC SA is a unidirectional entity between two end points: (SA) A ----------> B There is no such thing as one SA on A, and a different SA on B. SA's on both ends are just internal representation of the same logical SA. They *MUST* have all parameters equal, including lifetimes. Any other situation should be considered as error or undefined state. I hope above will be kept in the name of predictability and simplicity! If implementations want to break this "rule", they should be prepared to handle the "side effects" of the breaking without requiring changes to the other valid implementations (I guess the problem of lifetimes arises from the IKE omission that the responder does not have guaranteed way to communicate to the other end that it wants to change the proposed lifetimes -- conforming implementation can either accept them as is or reject. Right?) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Dec 2 13:55:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05881; Thu, 2 Dec 1999 13:55:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10918 Thu, 2 Dec 1999 15:32:36 -0500 (EST) Message-ID: <3846D7C2.58A34B8A@ire-ma.com> Date: Thu, 02 Dec 1999 15:34:10 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And related question - is it "legal" to use non-IP Address ID types (e.g. UFQDN, USER_FQDN, etc.) for the ID Type in the pre-shared keys authentication? This could help overcome NAT-related complications when negotiating with IPSec gateway behind it. Jan Vilhuber wrote: > A more interesting question, perhaps, and one we've been struggling with > as well, is: If you ignore the ID_IPV4 payload altogether, pick your key > based on the source-ip-address (which may be different than the IPV4 ID!), > does this open a security hole? > > I would argue that it doesn't and that you can safely ignore the ID payload > in the MM/pre-shared scenario, since it adds no value anyway. > > Donning flame-proof suit, > jan > > On Thu, 2 Dec 1999, Mike Carney wrote: > > > > Hi, > > > > > > Tylor Allison wrote: > > > > > > > I have a question that I hope some of you out there can help me answer. > > > > The scenario is this: Say I have a host machine using IKE/IPSEC which has > > > > multiple aliases for the same interface (or multiple interfaces routable > > > > to the same remote peer). When I start a IKE negotiation to the remote peer > > > > the IKE implementation does not have control over which interface address > > > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the > > > > identity payload, my IKE implementation will choose the IPV4 address to use > > > > in the ID payload based on the IKE implementations configured policy. > > > > > > > > My question is, what happens if the IPV4 address selected in the ID payload > > > > does not match the actual source address contained in the packet? > > > > I know for > > > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase > > > > 1 using Main Mode), since the actual remote address used to send the packet > > > > is used to determine the pre-shared key used to authenticate the session. > > > > This is the question at hand ... > > > > > > But how should this be handled for signature based authentication? If the > > > > IPV4 address specified in the identity payload matches the IP address in > > > > the subjectAltName extension of the cert used for sig authentication and > > > > this matches the IKE local policy, does it need to match the actual > > > > address received from the packet? > > > > Any suggestions? > > > > > > > > > > And what if there is no ip address in the subject-alt name? Is it then > > > > a requirement that the actual gateway match the IPV4_ADDR identity? > > > > > > > > How would implementations out there handle this scenario? Has anyone > > > > else thought of how to handle multiple interface aliases so that ISAKMP > > > > does "the right thing". > > > > > > This problem can be solved if you use identification other than > > > IP address, in case of signature authentication mode. > > > > No fair changing the problem to one that is easier to solve :) > > > > > > > > In case of preshared key authentication, while configuring the > > > IKE policy, one should know the source IP adress and inform > > > other end. > > > > > > > Who should know the source IP address? > > > > Consider the case of a box with multiple network interface cards and > > perhaps aliased IP address on some of those interfaces. The route to > > the remote peer is what determines the interface used to send the UDP packets > > that are sent by ISAKMP. The OS uses some heuristic to determine the > > aliase IP that is used to set the source address of packets from a > > given interface. > > > > Both the route and aliase choice are subject to change. > > > > I admit this is somewhat of a rare case as most VPN gateways > > have but a single IP address for all of the VPN traffic. But in > > our implementation it is a situation we must consider. > > > > Regards, > > Michael Carney > > > > > > > > > > > > > > > > Thanks in advance. > > > > > > > > --- > > > > Tylor Allison tylor_allison@securecomputing.com > > > > Secure Computing Corporation > > > > > > Regards > > > Srini > > > > > > > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Thu Dec 2 14:02:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05988; Thu, 2 Dec 1999 14:02:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10853 Thu, 2 Dec 1999 15:25:15 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5C47@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Thu, 2 Dec 1999 15:30:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: December 2, 1999 3:15 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > On Thu, 02 Dec 1999 15:05:39 EST you wrote oo. > > I'll ask again: why wouldn't anyone use the responder-lifetime > notify for lifetimes which are greater than the configured value > and respect the lifetimes of offers which are less than the > configured value? The reasons are irrelevant. The simple fact is that you might have to interoperate with an implementation that legally doesn't do that. If you make the assumption that every implementation does that, there's a potential interoperability problem. If you don't care about interoperating with those implementations, then I guess that's your choice. But in the customer's eyes, there's a chance either implementation or both are going to look bad. And in either case, it makes IPsec look bad. (Customer: Is one violating the specifications? Answer: No. Customer: But they don't work together!!! Answer: Well, only under certain circumstances....) > > Dan. > From owner-ipsec@lists.tislabs.com Thu Dec 2 14:31:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06359; Thu, 2 Dec 1999 14:31:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10939 Thu, 2 Dec 1999 15:42:07 -0500 (EST) Message-Id: <3.0.5.32.19991202152447.00bba100@hub.ecutel.com> X-Sender: qzhang@hub.ecutel.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 02 Dec 1999 15:24:47 -0500 To: Mike Carney From: Qiang Zhang Subject: Re: matching GW addr to ID payload (fwd) Cc: Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@securecomputing.com, carney@jumpsrv.stp.securecomputing.com In-Reply-To: <199912021824.MAA05280@jumpsrv.stp.securecomputing.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Somehow if the src-addr problem in the IKE won't be changed, then I guess the way out is to put both client and gateway in a tunnel mode, so that will be able to fix at least the peers' IP addrs for IKE negotiation. Best Regards, Qiang At 12:24 PM 12/2/99 -0600, Mike Carney wrote: >> Hi, >> >> Tylor Allison wrote: >> >> > I have a question that I hope some of you out there can help me answer. >> > The scenario is this: Say I have a host machine using IKE/IPSEC which has >> > multiple aliases for the same interface (or multiple interfaces routable >> > to the same remote peer). When I start a IKE negotiation to the remote peer >> > the IKE implementation does not have control over which interface address >> > gets inserted in the UDP packet. If I wish to use an IPV4 address in the >> > identity payload, my IKE implementation will choose the IPV4 address to use >> > in the ID payload based on the IKE implementations configured policy. >> > >> > My question is, what happens if the IPV4 address selected in the ID payload >> > does not match the actual source address contained in the packet? >> > I know for >> > the pre-shared key case, this won't (or shouldn't) work (at least for Phase >> > 1 using Main Mode), since the actual remote address used to send the packet >> > is used to determine the pre-shared key used to authenticate the session. > >This is the question at hand ... > >> > But how should this be handled for signature based authentication? If the >> > IPV4 address specified in the identity payload matches the IP address in >> > the subjectAltName extension of the cert used for sig authentication and >> > this matches the IKE local policy, does it need to match the actual >> > address received from the packet? > >Any suggestions? > >> > >> > And what if there is no ip address in the subject-alt name? Is it then >> > a requirement that the actual gateway match the IPV4_ADDR identity? >> > >> > How would implementations out there handle this scenario? Has anyone >> > else thought of how to handle multiple interface aliases so that ISAKMP >> > does "the right thing". >> >> This problem can be solved if you use identification other than >> IP address, in case of signature authentication mode. > >No fair changing the problem to one that is easier to solve :) > >> >> In case of preshared key authentication, while configuring the >> IKE policy, one should know the source IP adress and inform >> other end. >> > >Who should know the source IP address? > >Consider the case of a box with multiple network interface cards and >perhaps aliased IP address on some of those interfaces. The route to >the remote peer is what determines the interface used to send the UDP packets >that are sent by ISAKMP. The OS uses some heuristic to determine the >aliase IP that is used to set the source address of packets from a >given interface. > >Both the route and aliase choice are subject to change. > >I admit this is somewhat of a rare case as most VPN gateways >have but a single IP address for all of the VPN traffic. But in >our implementation it is a situation we must consider. > >Regards, >Michael Carney > > >> > >> > >> > Thanks in advance. >> > >> > --- >> > Tylor Allison tylor_allison@securecomputing.com >> > Secure Computing Corporation >> >> Regards >> Srini >> >> > > > > From owner-ipsec@lists.tislabs.com Thu Dec 2 14:47:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06606; Thu, 2 Dec 1999 14:47:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11063 Thu, 2 Dec 1999 16:23:44 -0500 (EST) Message-ID: <3846E4F8.963F9888@ibondinc.com> Date: Thu, 02 Dec 1999 13:30:33 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: Jan Vilhuber , Mike Carney , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: <3846D7C2.58A34B8A@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan wrote: > And related question - is it "legal" to use non-IP Address ID types (e.g. UFQDN, > USER_FQDN, etc.) for the ID Type in the pre-shared keys authentication? I guess it is possible. Why do you think it may not be legal? > > > This could help overcome NAT-related complications when negotiating with IPSec gateway > behind it. > > Jan Vilhuber wrote: > > > A more interesting question, perhaps, and one we've been struggling with > > as well, is: If you ignore the ID_IPV4 payload altogether, pick your key > > based on the source-ip-address (which may be different than the IPV4 ID!), > > does this open a security hole? > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > Donning flame-proof suit, > > jan > > > > On Thu, 2 Dec 1999, Mike Carney wrote: > > > > > > Hi, > > > > > > > > Tylor Allison wrote: > > > > > > > > > I have a question that I hope some of you out there can help me answer. > > > > > The scenario is this: Say I have a host machine using IKE/IPSEC which has > > > > > multiple aliases for the same interface (or multiple interfaces routable > > > > > to the same remote peer). When I start a IKE negotiation to the remote peer > > > > > the IKE implementation does not have control over which interface address > > > > > gets inserted in the UDP packet. If I wish to use an IPV4 address in the > > > > > identity payload, my IKE implementation will choose the IPV4 address to use > > > > > in the ID payload based on the IKE implementations configured policy. > > > > > > > > > > My question is, what happens if the IPV4 address selected in the ID payload > > > > > does not match the actual source address contained in the packet? > > > > > I know for > > > > > the pre-shared key case, this won't (or shouldn't) work (at least for Phase > > > > > 1 using Main Mode), since the actual remote address used to send the packet > > > > > is used to determine the pre-shared key used to authenticate the session. > > > > > > This is the question at hand ... > > > > > > > > But how should this be handled for signature based authentication? If the > > > > > IPV4 address specified in the identity payload matches the IP address in > > > > > the subjectAltName extension of the cert used for sig authentication and > > > > > this matches the IKE local policy, does it need to match the actual > > > > > address received from the packet? > > > > > > Any suggestions? > > > > > > > > > > > > > And what if there is no ip address in the subject-alt name? Is it then > > > > > a requirement that the actual gateway match the IPV4_ADDR identity? > > > > > > > > > > How would implementations out there handle this scenario? Has anyone > > > > > else thought of how to handle multiple interface aliases so that ISAKMP > > > > > does "the right thing". > > > > > > > > This problem can be solved if you use identification other than > > > > IP address, in case of signature authentication mode. > > > > > > No fair changing the problem to one that is easier to solve :) > > > > > > > > > > > In case of preshared key authentication, while configuring the > > > > IKE policy, one should know the source IP adress and inform > > > > other end. > > > > > > > > > > Who should know the source IP address? > > > > > > Consider the case of a box with multiple network interface cards and > > > perhaps aliased IP address on some of those interfaces. The route to > > > the remote peer is what determines the interface used to send the UDP packets > > > that are sent by ISAKMP. The OS uses some heuristic to determine the > > > aliase IP that is used to set the source address of packets from a > > > given interface. > > > > > > Both the route and aliase choice are subject to change. > > > > > > I admit this is somewhat of a rare case as most VPN gateways > > > have but a single IP address for all of the VPN traffic. But in > > > our implementation it is a situation we must consider. > > > > > > Regards, > > > Michael Carney > > > > > > > > > > > > > > > > > > > > > Thanks in advance. > > > > > > > > > > --- > > > > > Tylor Allison tylor_allison@securecomputing.com > > > > > Secure Computing Corporation > > > > > > > > Regards > > > > Srini > > > > > > > > > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-539-4816 > http://www.ire.com Regards Srini From owner-ipsec@lists.tislabs.com Thu Dec 2 14:53:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06680; Thu, 2 Dec 1999 14:53:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11095 Thu, 2 Dec 1999 16:31:55 -0500 (EST) Date: Thu, 2 Dec 1999 16:35:14 -0500 Message-Id: <199912022135.QAA20195@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: msa@hemuli.tte.vtt.fi Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3846B93C.F0216F51@ibondinc.com> <199912022033.WAA15645@anise.tte.vtt.fi> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Markku" == Markku Savela writes: >> Since life times may not be same on both ends, I also feel that we >> need to send Deletes to other end when IPSEC SA hard life time >> expires. Markku> I claim: Markku> An IPSEC SA is a unidirectional entity between two end Markku> points: Markku> (SA) A ----------> B Markku> There is no such thing as one SA on A, and a different SA on Markku> B. SA's on both ends are just internal representation of the Markku> same logical SA. They *MUST* have all parameters equal, Markku> including lifetimes. Any other situation should be considered Markku> as error or undefined state. That is a reasonable sounding definition but it is NOT the current definition. In particular, the notion that all parameters of the SA state as kept at the two ends of the SA must match is not in the current spec. paul From owner-ipsec@lists.tislabs.com Thu Dec 2 14:56:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06701; Thu, 2 Dec 1999 14:56:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11103 Thu, 2 Dec 1999 16:33:02 -0500 (EST) Message-Id: <199912022134.NAA14336@potassium.network-alchemy.com> To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: srao@ibondinc.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Thu, 02 Dec 1999 22:33:56 +0200." <199912022033.WAA15645@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14333.944170446.1@network-alchemy.com> Date: Thu, 02 Dec 1999 13:34:06 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > Since life times may not be same on both ends, I also feel that we need > > to send Deletes to other end when IPSEC SA hard life time expires. > > I claim: > > An IPSEC SA is a unidirectional entity between two end points: > > (SA) > A ----------> B > > There is no such thing as one SA on A, and a different SA on B. SA's > on both ends are just internal representation of the same logical > SA. They *MUST* have all parameters equal, including lifetimes. Any > other situation should be considered as error or undefined state. > > I hope above will be kept in the name of predictability and > simplicity! Yes, me too. > If implementations want to break this "rule", they should be prepared > to handle the "side effects" of the breaking without requiring changes > to the other valid implementations (I guess the problem of lifetimes > arises from the IKE omission that the responder does not have > guaranteed way to communicate to the other end that it wants to change > the proposed lifetimes -- conforming implementation can either accept > them as is or reject. Right?) No it can use the responder-lifetime message if it doesn't want to accept the offer as is. But your absolutely right that implementations that break this rule suffer undesirable side effects and need some other mechanism like always keeping an IKE SA around, and always sending delete messages, and alway assuming that the other party processes deletes, and binding the IPSec SA to the IKE SA in a manner which is not inferred by any of the relevant RFCs. Dan. From owner-ipsec@lists.tislabs.com Thu Dec 2 15:19:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06884; Thu, 2 Dec 1999 15:19:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11275 Thu, 2 Dec 1999 17:01:53 -0500 (EST) Message-Id: <199912022103.NAA14162@potassium.network-alchemy.com> To: Tim Jenkins cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-reply-to: Your message of "Thu, 02 Dec 1999 15:30:31 EST." <319A1C5F94C8D11192DE00805FBBADDFFD5C47@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14159.944168603.1@network-alchemy.com> Date: Thu, 02 Dec 1999 13:03:23 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please re-read this after s/responder-lifetime/delete payload/g. How do you intend on interoperating with someone who never sends a delete payload and doesn't process them? What will you tell the customer? "Is one of them violating the specifications?" Allow me to point out that the observation "but everyone implements the delete payload" is countered by your second statement. It seems to me that one can avoid all these rekeying issues by simply implementing a very common sense feature in the protocol or one avoid them by implementing a very complex, (let me use this term again because I love it) Rube Goldbergian system. Dan. On Thu, 02 Dec 1999 15:30:31 EST you wrote > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > > Sent: December 2, 1999 3:15 PM > > To: Tim Jenkins > > Cc: ipsec@lists.tislabs.com > > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > > > > On Thu, 02 Dec 1999 15:05:39 EST you wrote > oo. > > > > I'll ask again: why wouldn't anyone use the responder-lifetime > > notify for lifetimes which are greater than the configured value > > and respect the lifetimes of offers which are less than the > > configured value? > > The reasons are irrelevant. The simple fact is that you might > have to interoperate with an implementation that legally doesn't > do that. > > If you make the assumption that every implementation does that, > there's a potential interoperability problem. If you don't care > about interoperating with those implementations, then I guess > that's your choice. But in the customer's eyes, there's a chance > either implementation or both are going to look bad. And in > either case, it makes IPsec look bad. > > (Customer: Is one violating the specifications? > Answer: No. > Customer: But they don't work together!!! > Answer: Well, only under certain circumstances....) > > > > > Dan. > > From owner-ipsec@lists.tislabs.com Thu Dec 2 16:03:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07376; Thu, 2 Dec 1999 16:03:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11548 Thu, 2 Dec 1999 17:46:50 -0500 (EST) Date: Fri, 3 Dec 1999 00:49:54 +0200 (EET) Message-Id: <199912022249.AAA00532@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jan Vilhuber Cc: Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: References: <199912021824.MAA05280@jumpsrv.stp.securecomputing.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > I would argue that it doesn't and that you can safely ignore the ID payload > in the MM/pre-shared scenario, since it adds no value anyway. For pre shared keys it doesn't offer anything. You have to know the identity before ID payload anyways, because you need to select the correct pre shared key before you can decrypt the ID payload. You can use ID payload as a key to select correct policy for the quick mode, but I don't think there is any use to require it to match the IP address of the policy. This only applies for the pre shared keys. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 2 16:07:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07413; Thu, 2 Dec 1999 16:07:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11594 Thu, 2 Dec 1999 17:49:18 -0500 (EST) Date: Fri, 3 Dec 1999 00:52:39 +0200 (EET) Message-Id: <199912022252.AAA24109@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Tim Jenkins Cc: Dan Harkins , ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFD5C1A@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFFD5C1A@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins writes: > > If people are worried about being nice net citizens then use > > the responder- > > lifetime notify. It's very nice. > I agree 100% that it's very nice. But the reality is that > it is optional, so you cannot know 100% of the time that > the peer supports it. So, if someone wants to be a nice > net citizen, why would they say "screw you if you don't > use the responder lifetime notify"? s/responder lifetime notify/delete notifications/g This same paragraph can be used when arguing about use of the delete payloads. Both are optional, and you cannot be 100% sure that the other end supports it. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 2 16:10:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07477; Thu, 2 Dec 1999 16:10:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11789 Thu, 2 Dec 1999 18:02:17 -0500 (EST) Message-ID: <3846FB90.6FA5A7A1@ibondinc.com> Date: Thu, 02 Dec 1999 15:06:57 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > So if both responder lifetime and delete notifications are something anyone > in their right minds would implement, why don't we solve this whole debate by > changing them to MUST in the new version? > > If they remain SHOULD, then you can't assume that the remote has implemented > this. Despite it being common-sense, there's still implementors out there > that implement the bare necessities, i.e. only the MUSTs. If we really think > this is common-sense to implement, then what's the objection to making thing > like that a MUST? > > jan Yes. I agree with you and make it MUST to remove any ambiguities. Regards Srini > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > I claim: > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > (SA) > > > A ----------> B > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > on both ends are just internal representation of the same logical > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > other situation should be considered as error or undefined state. > > > > > > I hope above will be kept in the name of predictability and > > > simplicity! > > > > Yes, me too. > > > > > If implementations want to break this "rule", they should be prepared > > > to handle the "side effects" of the breaking without requiring changes > > > to the other valid implementations (I guess the problem of lifetimes > > > arises from the IKE omission that the responder does not have > > > guaranteed way to communicate to the other end that it wants to change > > > the proposed lifetimes -- conforming implementation can either accept > > > them as is or reject. Right?) > > > > No it can use the responder-lifetime message if it doesn't want to accept > > the offer as is. But your absolutely right that implementations that > > break this rule suffer undesirable side effects and need some other > > mechanism like always keeping an IKE SA around, and always sending delete > > messages, and alway assuming that the other party processes deletes, and > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > any of the relevant RFCs. > > > > Dan. > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 16:13:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07533; Thu, 2 Dec 1999 16:13:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11765 Thu, 2 Dec 1999 17:57:20 -0500 (EST) Message-ID: <3846FAE9.F8FCED36@ibondinc.com> Date: Thu, 02 Dec 1999 15:04:10 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Tim Jenkins , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <199912022015.MAA13876@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > On Thu, 02 Dec 1999 15:05:39 EST you wrote > > > > The lifetime setting stuff can be used to determine who > > initiates and when the re-keying is done. That's a > > different problem than dealt with by the draft. The > > only thing the draft intends to suggest about that is > > that you try avoid simultaneous re-keying in both > > directions. And you're right, if everyone used the > > responder lifetime notification, a simple rule > > could have been that only the initiator initiates re-keys. > > But that rule is unnecessary. Just rekey at X% of the lifetime > with some jitter. I may make X=98 and you may make X=97 or > whatever it doesn't matter. And if you talk to your own box > then even if you both have identical values of X the jitter > will make simultaneous rekey very unlikely. And even if it > happens, so what? > > > > If people are worried about being nice net citizens then use > > > the responder- > > > lifetime notify. It's very nice. > > > > I agree 100% that it's very nice. But the reality is that > > it is optional, so you cannot know 100% of the time that > > the peer supports it. So, if someone wants to be a nice > > net citizen, why would they say "screw you if you don't > > use the responder lifetime notify"? > > But as Kivinen pointed out, deletes are optional too. And > I'm not advocating saying "screw you" I'm saying that your > problems will go away if you just Do The Right Thing. Yes, > doing the right thing is optional but if you don't you have > problems that require a whole bunch of extra work to fix (and > causes other work which requires more fixing) and some of > this work is based on other optional features being implemented > too. > > I'll ask again: why wouldn't anyone use the responder-lifetime > notify for lifetimes which are greater than the configured value > and respect the lifetimes of offers which are less than the > configured value? I guess this is right thing to do and all implementation must follow this. For this, it needs to be mandated in the draft. In our implementation, we do send Responder-life time and process this. Also we do send Deletes to take care of implementation which donot process/generate responder-life time notification. If it is mandated, atleast some operations can be saved, such as sending Deletes and negotiating IKE SA to send Deletes etc.. > > > Dan. Regards Srini From owner-ipsec@lists.tislabs.com Thu Dec 2 16:17:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07609; Thu, 2 Dec 1999 16:17:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11798 Thu, 2 Dec 1999 18:02:31 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 15:05:14 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <199912022249.AAA00532@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Tero Kivinen wrote: > Jan Vilhuber writes: > > I would argue that it doesn't and that you can safely ignore the ID payload > > in the MM/pre-shared scenario, since it adds no value anyway. > > For pre shared keys it doesn't offer anything. You have to know the > identity before ID payload anyways, because you need to select the > correct pre shared key before you can decrypt the ID payload. You can > use ID payload as a key to select correct policy for the quick mode, > but I don't think there is any use to require it to match the IP > address of the policy. This only applies for the pre shared keys. But if you don't 'authenticate' the ID payload in any way, I would think it's insecure to select policy with it. Since PC-clients (or at least the one I'm familiar with) generally have the ID field as a configuration option, I could put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? How would you know that I was NOT 'kivinen@iki.fi'? Personally, I feel the ID in MM/pre-shared is pretty much superfluous and should be ignored and not used for anything at all. Aggressive mode is different, since I have the option of picking the shared secret based on the ID, so I can use it for policy selection (or whatever). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 16:18:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07627; Thu, 2 Dec 1999 16:18:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11714 Thu, 2 Dec 1999 17:54:42 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 14:57:31 -0800 (PST) From: Jan Vilhuber To: Dan Harkins cc: Markku Savela , srao@ibondinc.com, ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912022134.NAA14336@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So if both responder lifetime and delete notifications are something anyone in their right minds would implement, why don't we solve this whole debate by changing them to MUST in the new version? If they remain SHOULD, then you can't assume that the remote has implemented this. Despite it being common-sense, there's still implementors out there that implement the bare necessities, i.e. only the MUSTs. If we really think this is common-sense to implement, then what's the objection to making thing like that a MUST? jan On Thu, 2 Dec 1999, Dan Harkins wrote: > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > Since life times may not be same on both ends, I also feel that we need > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > I claim: > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > (SA) > > A ----------> B > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > on both ends are just internal representation of the same logical > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > other situation should be considered as error or undefined state. > > > > I hope above will be kept in the name of predictability and > > simplicity! > > Yes, me too. > > > If implementations want to break this "rule", they should be prepared > > to handle the "side effects" of the breaking without requiring changes > > to the other valid implementations (I guess the problem of lifetimes > > arises from the IKE omission that the responder does not have > > guaranteed way to communicate to the other end that it wants to change > > the proposed lifetimes -- conforming implementation can either accept > > them as is or reject. Right?) > > No it can use the responder-lifetime message if it doesn't want to accept > the offer as is. But your absolutely right that implementations that > break this rule suffer undesirable side effects and need some other > mechanism like always keeping an IKE SA around, and always sending delete > messages, and alway assuming that the other party processes deletes, and > binding the IPSec SA to the IKE SA in a manner which is not inferred by > any of the relevant RFCs. > > Dan. > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 16:20:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07671; Thu, 2 Dec 1999 16:20:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11994 Thu, 2 Dec 1999 18:14:12 -0500 (EST) Date: Fri, 3 Dec 1999 01:17:36 +0200 (EET) Message-Id: <199912022317.BAA29368@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jan Vilhuber Cc: Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: References: <199912022249.AAA00532@torni.ssh.fi> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > But if you don't 'authenticate' the ID payload in any way, I would think it's You did authenticate it, it is something the other end sent to you, and it is authenticated because the hash that the other end calculated using pre-shared key was correct. So ID payload is authenticated to be sent by the other end. How much you can trust to it is another matter, but it is authenticated. > insecure to select policy with it. Since PC-clients (or at least the one I'm > familiar with) generally have the ID field as a configuration option, I could > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > How would you know that I was NOT 'kivinen@iki.fi'? I would you use the ip address as a primary key and if that key says to me that this is laptop shared between you and me, and the ID payload says it is kivinen@iki.fi, then the gw should use kivinen@iki.fi's policy rules not yours... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 2 16:44:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08085; Thu, 2 Dec 1999 16:44:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12214 Thu, 2 Dec 1999 18:32:50 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 15:35:50 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <199912022317.BAA29368@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Tero Kivinen wrote: > Jan Vilhuber writes: > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > You did authenticate it, it is something the other end sent to you, > and it is authenticated because the hash that the other end calculated > using pre-shared key was correct. > > So ID payload is authenticated to be sent by the other end. How much > you can trust to it is another matter, but it is authenticated. > Maybe this is semantics, but since the ID was not involved with the selection of the pre-shared key, then it's not authenticated. The fact that it's in the hash means only that both sides used the same value to stick into the hash, but not that it's authenticated (unless I'm missing something). > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > familiar with) generally have the ID field as a configuration option, I could > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > How would you know that I was NOT 'kivinen@iki.fi'? > > I would you use the ip address as a primary key and if that key says > to me that this is laptop shared between you and me, and the ID > payload says it is kivinen@iki.fi, then the gw should use > kivinen@iki.fi's policy rules not yours... I suppose bringing up group-keys at this point wouldn't get us very far, so I'll leave it out. If you assume that kivinen@iki.fi always has the same IP address, then I agree this would work. However when (dynamic) NAT and dynamic-ip-addresses are involved, this no longer works, but then you shouldn't be using pre-shared keys for that anyway. Not that that's stopping people... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 16:58:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08275; Thu, 2 Dec 1999 16:58:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12341 Thu, 2 Dec 1999 18:53:37 -0500 (EST) Message-ID: <3847068A.4E3E87B5@ire-ma.com> Date: Thu, 02 Dec 1999 18:53:46 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Srinivasa Rao Addepalli CC: Jan Vilhuber , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3846FB90.6FA5A7A1@ibondinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Apart from resource management concerns I do not see any drawbacks for re-keying IKE SA immediately after it is expired or deleted (assuming that there are active IPSec SA existed under old IKE SA). But, I think, this scheme schould not me mandated by the standards - it should be left to individual implementations or policies. The benefits of such logic will be ability to send protected Informational Exchanges at ALL times, including protected keep-alives and DELETEs. Srinivasa Rao Addepalli wrote: > Jan Vilhuber wrote: > > > So if both responder lifetime and delete notifications are something anyone > > in their right minds would implement, why don't we solve this whole debate by > > changing them to MUST in the new version? > > > > If they remain SHOULD, then you can't assume that the remote has implemented > > this. Despite it being common-sense, there's still implementors out there > > that implement the bare necessities, i.e. only the MUSTs. If we really think > > this is common-sense to implement, then what's the objection to making thing > > like that a MUST? > > > > jan > > Yes. I agree with you and make it MUST to remove any ambiguities. > > Regards > Srini > > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > > > I claim: > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > (SA) > > > > A ----------> B > > > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > > on both ends are just internal representation of the same logical > > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > > other situation should be considered as error or undefined state. > > > > > > > > I hope above will be kept in the name of predictability and > > > > simplicity! > > > > > > Yes, me too. > > > > > > > If implementations want to break this "rule", they should be prepared > > > > to handle the "side effects" of the breaking without requiring changes > > > > to the other valid implementations (I guess the problem of lifetimes > > > > arises from the IKE omission that the responder does not have > > > > guaranteed way to communicate to the other end that it wants to change > > > > the proposed lifetimes -- conforming implementation can either accept > > > > them as is or reject. Right?) > > > > > > No it can use the responder-lifetime message if it doesn't want to accept > > > the offer as is. But your absolutely right that implementations that > > > break this rule suffer undesirable side effects and need some other > > > mechanism like always keeping an IKE SA around, and always sending delete > > > messages, and alway assuming that the other party processes deletes, and > > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > > any of the relevant RFCs. > > > > > > Dan. > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:05:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08404; Thu, 2 Dec 1999 17:05:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12312 Thu, 2 Dec 1999 18:47:09 -0500 (EST) Message-ID: <384704D3.AD6B533@ire-ma.com> Date: Thu, 02 Dec 1999 18:46:29 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, You said "How would you know that I was NOT 'kivinen@iki.fi'?" That's true - but the similar question could be asked: "How would you know that my IP Address is NOT 204.12.57.121"? Both schemes have exactly the same level of insecurity (though changing IP Address on my machine is much easier than changing the content of the ID Payload :). But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload and get through the NAT and do not make the special case for not checking ID Payload when using pre-shared key in MM. Another option in the new draft could be to remove ID Payload altogether for MMs with pre-shared keys. Jan Vilhuber wrote: > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > Jan Vilhuber writes: > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > For pre shared keys it doesn't offer anything. You have to know the > > identity before ID payload anyways, because you need to select the > > correct pre shared key before you can decrypt the ID payload. You can > > use ID payload as a key to select correct policy for the quick mode, > > but I don't think there is any use to require it to match the IP > > address of the policy. This only applies for the pre shared keys. > > But if you don't 'authenticate' the ID payload in any way, I would think it's > insecure to select policy with it. Since PC-clients (or at least the one I'm > familiar with) generally have the ID field as a configuration option, I could > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > How would you know that I was NOT 'kivinen@iki.fi'? > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > should be ignored and not used for anything at all. > > Aggressive mode is different, since I have the option of picking the shared > secret based on the ID, so I can use it for policy selection (or whatever). > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:08:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08453; Thu, 2 Dec 1999 17:08:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12390 Thu, 2 Dec 1999 19:01:13 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 16:04:08 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <384704D3.AD6B533@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > Jan, > > You said "How would you know that I was NOT 'kivinen@iki.fi'?" > That's true - but the similar question could be asked: "How would you know > that my IP Address is NOT 204.12.57.121"? > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big difference. One selects the key, and one does not. > Both schemes have exactly the same level of insecurity (though changing IP > Address on my machine is much easier than changing the content of the ID > Payload :). > No, they don't, but I may be missing something: If you change your ip-address (barring NAT) I would pick a key based on the source-ip-address. So this does have implications. If you change the ID, nothing changes, except the string of bits that goes into the hash. There's a difference. > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload > and get through the NAT and do not make the special case for not checking > ID Payload when using pre-shared key in MM. > What does checking the ID payload give you? I can't CHECK that you are 'cisco-gateway.com'. And I personally don't care if your ID payload claims you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor are they particularly reliable, since you could be lying about them, and I have no way of knowing. So I ignore them, and pick the key based on source-ip-address (the only thing I CAN). > Another option in the new draft could be to remove ID Payload altogether > for MMs with pre-shared keys. > Either way, I don't get your points above. The problem is solved if you simply ignore the ID payload in this situation. Pay no attention to it. I carries no relevant information. jan > Jan Vilhuber wrote: > > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > Jan Vilhuber writes: > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > > > For pre shared keys it doesn't offer anything. You have to know the > > > identity before ID payload anyways, because you need to select the > > > correct pre shared key before you can decrypt the ID payload. You can > > > use ID payload as a key to select correct policy for the quick mode, > > > but I don't think there is any use to require it to match the IP > > > address of the policy. This only applies for the pre shared keys. > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > familiar with) generally have the ID field as a configuration option, I could > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > How would you know that I was NOT 'kivinen@iki.fi'? > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > > should be ignored and not used for anything at all. > > > > Aggressive mode is different, since I have the option of picking the shared > > secret based on the ID, so I can use it for policy selection (or whatever). > > > > jan > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:47:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08759; Thu, 2 Dec 1999 17:46:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12533 Thu, 2 Dec 1999 19:38:11 -0500 (EST) Message-ID: <384710FC.11BF547F@ire-ma.com> Date: Thu, 02 Dec 1999 19:38:21 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You missed to read very first words in my mail - "Apart from resource management concerns.....". Jan Vilhuber wrote: > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > Apart from resource management concerns I do not see any drawbacks for re-keying > > IKE SA immediately after it is expired or deleted (assuming that there are active > > IPSec SA existed under old IKE SA). > > > > But, I think, this scheme schould not me mandated by the standards - it should be > > left to individual implementations or policies. > > Yes and no. As Tero pointed out (or was it Dan? I forget) if someone deleted > their IKE SA for resource-recovery reasons (short of memory.. whatever) > you're REALLY not doing them a favor by rekeying immediately. > > One might almost argue that we should add verbiage to the rfc that says > something like "MUST not rekey unless the SA is really needed" (for some > definition of 'really needed'). > > jan > > > The benefits of such logic will be ability to send protected Informational > > Exchanges at ALL times, including protected keep-alives and DELETEs. > > > > Srinivasa Rao Addepalli wrote: > > > > > Jan Vilhuber wrote: > > > > > > > So if both responder lifetime and delete notifications are something anyone > > > > in their right minds would implement, why don't we solve this whole debate by > > > > changing them to MUST in the new version? > > > > > > > > If they remain SHOULD, then you can't assume that the remote has implemented > > > > this. Despite it being common-sense, there's still implementors out there > > > > that implement the bare necessities, i.e. only the MUSTs. If we really think > > > > this is common-sense to implement, then what's the objection to making thing > > > > like that a MUST? > > > > > > > > jan > > > > > > Yes. I agree with you and make it MUST to remove any ambiguities. > > > > > > Regards > > > Srini > > > > > > > > > > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > > > > > > > I claim: > > > > > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > > > > > (SA) > > > > > > A ----------> B > > > > > > > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > > > > on both ends are just internal representation of the same logical > > > > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > > > > other situation should be considered as error or undefined state. > > > > > > > > > > > > I hope above will be kept in the name of predictability and > > > > > > simplicity! > > > > > > > > > > Yes, me too. > > > > > > > > > > > If implementations want to break this "rule", they should be prepared > > > > > > to handle the "side effects" of the breaking without requiring changes > > > > > > to the other valid implementations (I guess the problem of lifetimes > > > > > > arises from the IKE omission that the responder does not have > > > > > > guaranteed way to communicate to the other end that it wants to change > > > > > > the proposed lifetimes -- conforming implementation can either accept > > > > > > them as is or reject. Right?) > > > > > > > > > > No it can use the responder-lifetime message if it doesn't want to accept > > > > > the offer as is. But your absolutely right that implementations that > > > > > break this rule suffer undesirable side effects and need some other > > > > > mechanism like always keeping an IKE SA around, and always sending delete > > > > > messages, and alway assuming that the other party processes deletes, and > > > > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > > > > any of the relevant RFCs. > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:47:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08769; Thu, 2 Dec 1999 17:47:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12508 Thu, 2 Dec 1999 19:32:50 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 16:35:53 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <3847068A.4E3E87B5@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > Apart from resource management concerns I do not see any drawbacks for re-keying > IKE SA immediately after it is expired or deleted (assuming that there are active > IPSec SA existed under old IKE SA). > > But, I think, this scheme schould not me mandated by the standards - it should be > left to individual implementations or policies. Yes and no. As Tero pointed out (or was it Dan? I forget) if someone deleted their IKE SA for resource-recovery reasons (short of memory.. whatever) you're REALLY not doing them a favor by rekeying immediately. One might almost argue that we should add verbiage to the rfc that says something like "MUST not rekey unless the SA is really needed" (for some definition of 'really needed'). jan > The benefits of such logic will be ability to send protected Informational > Exchanges at ALL times, including protected keep-alives and DELETEs. > > Srinivasa Rao Addepalli wrote: > > > Jan Vilhuber wrote: > > > > > So if both responder lifetime and delete notifications are something anyone > > > in their right minds would implement, why don't we solve this whole debate by > > > changing them to MUST in the new version? > > > > > > If they remain SHOULD, then you can't assume that the remote has implemented > > > this. Despite it being common-sense, there's still implementors out there > > > that implement the bare necessities, i.e. only the MUSTs. If we really think > > > this is common-sense to implement, then what's the objection to making thing > > > like that a MUST? > > > > > > jan > > > > Yes. I agree with you and make it MUST to remove any ambiguities. > > > > Regards > > Srini > > > > > > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > > > > > I claim: > > > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > > > (SA) > > > > > A ----------> B > > > > > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > > > on both ends are just internal representation of the same logical > > > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > > > other situation should be considered as error or undefined state. > > > > > > > > > > I hope above will be kept in the name of predictability and > > > > > simplicity! > > > > > > > > Yes, me too. > > > > > > > > > If implementations want to break this "rule", they should be prepared > > > > > to handle the "side effects" of the breaking without requiring changes > > > > > to the other valid implementations (I guess the problem of lifetimes > > > > > arises from the IKE omission that the responder does not have > > > > > guaranteed way to communicate to the other end that it wants to change > > > > > the proposed lifetimes -- conforming implementation can either accept > > > > > them as is or reject. Right?) > > > > > > > > No it can use the responder-lifetime message if it doesn't want to accept > > > > the offer as is. But your absolutely right that implementations that > > > > break this rule suffer undesirable side effects and need some other > > > > mechanism like always keeping an IKE SA around, and always sending delete > > > > messages, and alway assuming that the other party processes deletes, and > > > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > > > any of the relevant RFCs. > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:47:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08784; Thu, 2 Dec 1999 17:47:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12549 Thu, 2 Dec 1999 19:40:26 -0500 (EST) Date: Thu, 2 Dec 1999 19:42:20 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <3846D7C2.58A34B8A@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Slava Kavsan wrote: > And related question - is it "legal" to use non-IP Address ID types (e.g. UFQDN, > USER_FQDN, etc.) for the ID Type in the pre-shared keys authentication? There's nothing illegal about it, but ID payloads are of limited utility with shared-secret authentication. As others have pointed out, you have to decide which shared secret to use -- to decrypt the message -- before you can see any ID payload. You could conceivably have multiple mobile machines sharing the same secret (not generally a good idea) and determine which is calling by using an ID payload. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Thu Dec 2 17:51:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08811; Thu, 2 Dec 1999 17:51:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12520 Thu, 2 Dec 1999 19:33:45 -0500 (EST) Message-ID: <38470FBF.CF2E2805@ire-ma.com> Date: Thu, 02 Dec 1999 19:33:04 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All I am saying - having 204.12.57.121 as a source-ip-address and in ID_IPV4 - has exactly the same level of insecurity as having 204.12.57.121 as a source-ip-address and "cisco-gateway.com" in ID Payload. Neither scheme is trustworthy, as you said, and therefore the question "How would you know that I was NOT 'kivinen@iki.fi'?" is irrelevant. The point I am making is one of the convienience for people who already have this code in place (and not of security) to continue to use ID Payloads for selecting the key and work through NAT. Or recognize the fact that ID Payloads in this scenario just useless bunch of bits and get rid of it in the standards - both ignoring ID Payload or changing standards to not use ID Payload - requires code changes in existing products. Jan Vilhuber wrote: > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > Jan, > > > > You said "How would you know that I was NOT 'kivinen@iki.fi'?" > > That's true - but the similar question could be asked: "How would you know > > that my IP Address is NOT 204.12.57.121"? > > > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big > difference. One selects the key, and one does not. > > > Both schemes have exactly the same level of insecurity (though changing IP > > Address on my machine is much easier than changing the content of the ID > > Payload :). > > > No, they don't, but I may be missing something: If you change your > ip-address (barring NAT) I would pick a key based on the source-ip-address. > So this does have implications. > > If you change the ID, nothing changes, except the string of bits that goes > into the hash. There's a difference. > > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload > > and get through the NAT and do not make the special case for not checking > > ID Payload when using pre-shared key in MM. > > > What does checking the ID payload give you? I can't CHECK that you are > 'cisco-gateway.com'. And I personally don't care if your ID payload claims > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor > are they particularly reliable, since you could be lying about them, and I > have no way of knowing. So I ignore them, and pick the key based on > source-ip-address (the only thing I CAN). > > > Another option in the new draft could be to remove ID Payload altogether > > for MMs with pre-shared keys. > > > Either way, I don't get your points above. The problem is solved if you > simply ignore the ID payload in this situation. Pay no attention to it. I > carries no relevant information. > > jan > > > Jan Vilhuber wrote: > > > > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > > Jan Vilhuber writes: > > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > > > > > For pre shared keys it doesn't offer anything. You have to know the > > > > identity before ID payload anyways, because you need to select the > > > > correct pre shared key before you can decrypt the ID payload. You can > > > > use ID payload as a key to select correct policy for the quick mode, > > > > but I don't think there is any use to require it to match the IP > > > > address of the policy. This only applies for the pre shared keys. > > > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > > familiar with) generally have the ID field as a configuration option, I could > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > > How would you know that I was NOT 'kivinen@iki.fi'? > > > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > > > should be ignored and not used for anything at all. > > > > > > Aggressive mode is different, since I have the option of picking the shared > > > secret based on the ID, so I can use it for policy selection (or whatever). > > > > > > jan > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:51:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08824; Thu, 2 Dec 1999 17:51:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12576 Thu, 2 Dec 1999 19:43:25 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 16:46:27 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <384710FC.11BF547F@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > You missed to read very first words in my mail - "Apart from resource management > concerns.....". > Well, yes, but resource concerns are driving at least part of this discussion. They are a large concern. If we agree that there may be resource concerns, then what's the point of the rest of your email? It's not like you (the peer) can distinguish whether I deleted my SA because I felt like it, or because or resource concerns. All YOU see is that I deleted it. So why do you feel the need to continue and state that you want the option to rekey immediately ANYWAY? You can't tell, so don't do it. jan > Jan Vilhuber wrote: > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > Apart from resource management concerns I do not see any drawbacks for re-keying > > > IKE SA immediately after it is expired or deleted (assuming that there are active > > > IPSec SA existed under old IKE SA). > > > > > > But, I think, this scheme schould not me mandated by the standards - it should be > > > left to individual implementations or policies. > > > > Yes and no. As Tero pointed out (or was it Dan? I forget) if someone deleted > > their IKE SA for resource-recovery reasons (short of memory.. whatever) > > you're REALLY not doing them a favor by rekeying immediately. > > > > One might almost argue that we should add verbiage to the rfc that says > > something like "MUST not rekey unless the SA is really needed" (for some > > definition of 'really needed'). > > > > jan > > > > > The benefits of such logic will be ability to send protected Informational > > > Exchanges at ALL times, including protected keep-alives and DELETEs. > > > > > > Srinivasa Rao Addepalli wrote: > > > > > > > Jan Vilhuber wrote: > > > > > > > > > So if both responder lifetime and delete notifications are something anyone > > > > > in their right minds would implement, why don't we solve this whole debate by > > > > > changing them to MUST in the new version? > > > > > > > > > > If they remain SHOULD, then you can't assume that the remote has implemented > > > > > this. Despite it being common-sense, there's still implementors out there > > > > > that implement the bare necessities, i.e. only the MUSTs. If we really think > > > > > this is common-sense to implement, then what's the objection to making thing > > > > > like that a MUST? > > > > > > > > > > jan > > > > > > > > Yes. I agree with you and make it MUST to remove any ambiguities. > > > > > > > > Regards > > > > Srini > > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > > > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > > > > > > > > > I claim: > > > > > > > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > > > > > > > (SA) > > > > > > > A ----------> B > > > > > > > > > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > > > > > on both ends are just internal representation of the same logical > > > > > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > > > > > other situation should be considered as error or undefined state. > > > > > > > > > > > > > > I hope above will be kept in the name of predictability and > > > > > > > simplicity! > > > > > > > > > > > > Yes, me too. > > > > > > > > > > > > > If implementations want to break this "rule", they should be prepared > > > > > > > to handle the "side effects" of the breaking without requiring changes > > > > > > > to the other valid implementations (I guess the problem of lifetimes > > > > > > > arises from the IKE omission that the responder does not have > > > > > > > guaranteed way to communicate to the other end that it wants to change > > > > > > > the proposed lifetimes -- conforming implementation can either accept > > > > > > > them as is or reject. Right?) > > > > > > > > > > > > No it can use the responder-lifetime message if it doesn't want to accept > > > > > > the offer as is. But your absolutely right that implementations that > > > > > > break this rule suffer undesirable side effects and need some other > > > > > > mechanism like always keeping an IKE SA around, and always sending delete > > > > > > messages, and alway assuming that the other party processes deletes, and > > > > > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > > > > > any of the relevant RFCs. > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 17:54:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08867; Thu, 2 Dec 1999 17:54:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12563 Thu, 2 Dec 1999 19:41:46 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 2 Dec 1999 16:44:37 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <38470FBF.CF2E2805@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > All I am saying - having 204.12.57.121 as a source-ip-address and in > ID_IPV4 - has exactly the same level of insecurity as having 204.12.57.121 > as a source-ip-address and "cisco-gateway.com" in ID Payload. Neither > scheme is trustworthy, as you said, and therefore the question "How would > you know that I was NOT 'kivinen@iki.fi'?" is irrelevant. > I suppose. I think that's what I was pointing out to begin with. The question can not be answered. > The point I am making is one of the convienience for people who already > have this code in place (and not of security) to continue to use ID > Payloads for selecting the key and work through NAT. Huh? If using MM with pre-shared keys, you can't use the ID payload to select the key. > Or recognize the fact > that ID Payloads in this scenario just useless bunch of bits and get rid of > it in the standards - both ignoring ID Payload or changing standards to not > use ID Payload - requires code changes in existing products. > Getting rid of your check that checks the ID_IPV4 against the source-ip-address seems to me to be rather simple (I seem to recall you saying it's a one-liner). Neither is illegal according to the rfc, as far as I can tell, but DOING that check, which is unnecessary, since it doesn't buy you anything, breaks some situations, so your implementation is not as flexible as one that simply ignores the ID payload. Whether or not we rewrite the rfc to exclude the ID from MM/pre-shared is irrelevant in that case. Bottom-line: ID payload in MM/pre-shared doesn't give you any usefull information and can not be checked for validity. So actually checking it is counter-productive. Unless someone can point out a fallacy in my thinking. Here's another approach: If we agree that it's valid to send ID_FQDN in MM/pre-shared, and you don't check this, then what do you gain by checking the ID payload when it's ID_IPV4? jan > Jan Vilhuber wrote: > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > Jan, > > > > > > You said "How would you know that I was NOT 'kivinen@iki.fi'?" > > > That's true - but the similar question could be asked: "How would you know > > > that my IP Address is NOT 204.12.57.121"? > > > > > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big > > difference. One selects the key, and one does not. > > > > > Both schemes have exactly the same level of insecurity (though changing IP > > > Address on my machine is much easier than changing the content of the ID > > > Payload :). > > > > > No, they don't, but I may be missing something: If you change your > > ip-address (barring NAT) I would pick a key based on the source-ip-address. > > So this does have implications. > > > > If you change the ID, nothing changes, except the string of bits that goes > > into the hash. There's a difference. > > > > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload > > > and get through the NAT and do not make the special case for not checking > > > ID Payload when using pre-shared key in MM. > > > > > What does checking the ID payload give you? I can't CHECK that you are > > 'cisco-gateway.com'. And I personally don't care if your ID payload claims > > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor > > are they particularly reliable, since you could be lying about them, and I > > have no way of knowing. So I ignore them, and pick the key based on > > source-ip-address (the only thing I CAN). > > > > > Another option in the new draft could be to remove ID Payload altogether > > > for MMs with pre-shared keys. > > > > > Either way, I don't get your points above. The problem is solved if you > > simply ignore the ID payload in this situation. Pay no attention to it. I > > carries no relevant information. > > > > jan > > > > > Jan Vilhuber wrote: > > > > > > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > > > Jan Vilhuber writes: > > > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > > > > > > > For pre shared keys it doesn't offer anything. You have to know the > > > > > identity before ID payload anyways, because you need to select the > > > > > correct pre shared key before you can decrypt the ID payload. You can > > > > > use ID payload as a key to select correct policy for the quick mode, > > > > > but I don't think there is any use to require it to match the IP > > > > > address of the policy. This only applies for the pre shared keys. > > > > > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > > > familiar with) generally have the ID field as a configuration option, I could > > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > > > How would you know that I was NOT 'kivinen@iki.fi'? > > > > > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > > > > should be ignored and not used for anything at all. > > > > > > > > Aggressive mode is different, since I have the option of picking the shared > > > > secret based on the ID, so I can use it for policy selection (or whatever). > > > > > > > > jan > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 18:08:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10023; Thu, 2 Dec 1999 18:08:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12610 Thu, 2 Dec 1999 19:56:40 -0500 (EST) Message-ID: <38471553.93FA1EB@ire-ma.com> Date: Thu, 02 Dec 1999 19:56:53 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If your gateway is running out of memory and deleted IKE SA to free some memory - when I want to send you keep-alive 1 min later and start IKE SA to protect it - you will have exactly the same resource problem as you had 1 min ago. Jan Vilhuber wrote: > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > You missed to read very first words in my mail - "Apart from resource management > > concerns.....". > > > Well, yes, but resource concerns are driving at least part of this > discussion. They are a large concern. If we agree that there may be resource > concerns, then what's the point of the rest of your email? It's not like you > (the peer) can distinguish whether I deleted my SA because I felt like it, or > because or resource concerns. All YOU see is that I deleted it. So why do you > feel the need to continue and state that you want the option to rekey > immediately ANYWAY? You can't tell, so don't do it. > > jan > > > Jan Vilhuber wrote: > > > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > > Apart from resource management concerns I do not see any drawbacks for re-keying > > > > IKE SA immediately after it is expired or deleted (assuming that there are active > > > > IPSec SA existed under old IKE SA). > > > > > > > > But, I think, this scheme schould not me mandated by the standards - it should be > > > > left to individual implementations or policies. > > > > > > Yes and no. As Tero pointed out (or was it Dan? I forget) if someone deleted > > > their IKE SA for resource-recovery reasons (short of memory.. whatever) > > > you're REALLY not doing them a favor by rekeying immediately. > > > > > > One might almost argue that we should add verbiage to the rfc that says > > > something like "MUST not rekey unless the SA is really needed" (for some > > > definition of 'really needed'). > > > > > > jan > > > > > > > The benefits of such logic will be ability to send protected Informational > > > > Exchanges at ALL times, including protected keep-alives and DELETEs. > > > > > > > > Srinivasa Rao Addepalli wrote: > > > > > > > > > Jan Vilhuber wrote: > > > > > > > > > > > So if both responder lifetime and delete notifications are something anyone > > > > > > in their right minds would implement, why don't we solve this whole debate by > > > > > > changing them to MUST in the new version? > > > > > > > > > > > > If they remain SHOULD, then you can't assume that the remote has implemented > > > > > > this. Despite it being common-sense, there's still implementors out there > > > > > > that implement the bare necessities, i.e. only the MUSTs. If we really think > > > > > > this is common-sense to implement, then what's the objection to making thing > > > > > > like that a MUST? > > > > > > > > > > > > jan > > > > > > > > > > Yes. I agree with you and make it MUST to remove any ambiguities. > > > > > > > > > > Regards > > > > > Srini > > > > > > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > > > > > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > > > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > > > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > > > > > > > > > > > I claim: > > > > > > > > > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > > > > > > > > > (SA) > > > > > > > > A ----------> B > > > > > > > > > > > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > > > > > > on both ends are just internal representation of the same logical > > > > > > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > > > > > > other situation should be considered as error or undefined state. > > > > > > > > > > > > > > > > I hope above will be kept in the name of predictability and > > > > > > > > simplicity! > > > > > > > > > > > > > > Yes, me too. > > > > > > > > > > > > > > > If implementations want to break this "rule", they should be prepared > > > > > > > > to handle the "side effects" of the breaking without requiring changes > > > > > > > > to the other valid implementations (I guess the problem of lifetimes > > > > > > > > arises from the IKE omission that the responder does not have > > > > > > > > guaranteed way to communicate to the other end that it wants to change > > > > > > > > the proposed lifetimes -- conforming implementation can either accept > > > > > > > > them as is or reject. Right?) > > > > > > > > > > > > > > No it can use the responder-lifetime message if it doesn't want to accept > > > > > > > the offer as is. But your absolutely right that implementations that > > > > > > > break this rule suffer undesirable side effects and need some other > > > > > > > mechanism like always keeping an IKE SA around, and always sending delete > > > > > > > messages, and alway assuming that the other party processes deletes, and > > > > > > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > > > > > > any of the relevant RFCs. > > > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 18:17:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA10919; Thu, 2 Dec 1999 18:17:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12592 Thu, 2 Dec 1999 19:51:15 -0500 (EST) Message-ID: <3847140D.6218D9@ire-ma.com> Date: Thu, 02 Dec 1999 19:51:26 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > Huh? If using MM with pre-shared keys, you can't use the ID payload to select > the key. Why not if I am a responder? How it is different from using source-ip-adress to select the key? > (I seem to recall you > saying it's a one-liner). Yeah.....it takes one line of code, but requires whole new Release and upgrading thousands of installations... > Whether or not we rewrite the rfc to exclude the ID from MM/pre-shared is > irrelevant in that case. > > Bottom-line: ID payload in MM/pre-shared doesn't give you any usefull > information and can not be checked for validity. So actually checking it is > counter-productive. > > Unless someone can point out a fallacy in my thinking. > > Here's another approach: If we agree that it's valid to send ID_FQDN in > MM/pre-shared, and you don't check this, then what do you gain by checking > the ID payload when it's ID_IPV4? > > jan > > > Jan Vilhuber wrote: > > > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > > Jan, > > > > > > > > You said "How would you know that I was NOT 'kivinen@iki.fi'?" > > > > That's true - but the similar question could be asked: "How would you know > > > > that my IP Address is NOT 204.12.57.121"? > > > > > > > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big > > > difference. One selects the key, and one does not. > > > > > > > Both schemes have exactly the same level of insecurity (though changing IP > > > > Address on my machine is much easier than changing the content of the ID > > > > Payload :). > > > > > > > No, they don't, but I may be missing something: If you change your > > > ip-address (barring NAT) I would pick a key based on the source-ip-address. > > > So this does have implications. > > > > > > If you change the ID, nothing changes, except the string of bits that goes > > > into the hash. There's a difference. > > > > > > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload > > > > and get through the NAT and do not make the special case for not checking > > > > ID Payload when using pre-shared key in MM. > > > > > > > What does checking the ID payload give you? I can't CHECK that you are > > > 'cisco-gateway.com'. And I personally don't care if your ID payload claims > > > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor > > > are they particularly reliable, since you could be lying about them, and I > > > have no way of knowing. So I ignore them, and pick the key based on > > > source-ip-address (the only thing I CAN). > > > > > > > Another option in the new draft could be to remove ID Payload altogether > > > > for MMs with pre-shared keys. > > > > > > > Either way, I don't get your points above. The problem is solved if you > > > simply ignore the ID payload in this situation. Pay no attention to it. I > > > carries no relevant information. > > > > > > jan > > > > > > > Jan Vilhuber wrote: > > > > > > > > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > > > > Jan Vilhuber writes: > > > > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > > > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > > > > > > > > > For pre shared keys it doesn't offer anything. You have to know the > > > > > > identity before ID payload anyways, because you need to select the > > > > > > correct pre shared key before you can decrypt the ID payload. You can > > > > > > use ID payload as a key to select correct policy for the quick mode, > > > > > > but I don't think there is any use to require it to match the IP > > > > > > address of the policy. This only applies for the pre shared keys. > > > > > > > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > > > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > > > > familiar with) generally have the ID field as a configuration option, I could > > > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > > > > How would you know that I was NOT 'kivinen@iki.fi'? > > > > > > > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > > > > > should be ignored and not used for anything at all. > > > > > > > > > > Aggressive mode is different, since I have the option of picking the shared > > > > > secret based on the ID, so I can use it for policy selection (or whatever). > > > > > > > > > > jan > > > > > -- > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 18:21:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11206; Thu, 2 Dec 1999 18:21:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12674 Thu, 2 Dec 1999 20:08:40 -0500 (EST) Message-ID: <38471824.DDC60425@ire-ma.com> Date: Thu, 02 Dec 1999 20:08:53 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber , Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: <3847140D.6218D9@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ooops - you are right - can't select the key based on ID Payload. But can verify that the policy entry selected based on source-ip-address is the same as pointed out by ID Payload. Bronislav Kavsan wrote: > Jan Vilhuber wrote: > > > Huh? If using MM with pre-shared keys, you can't use the ID payload to select > > the key. > > Why not if I am a responder? How it is different from using source-ip-adress to select the > key? > > > (I seem to recall you > > saying it's a one-liner). > > Yeah.....it takes one line of code, but requires whole new Release and upgrading thousands > of installations... > > > Whether or not we rewrite the rfc to exclude the ID from MM/pre-shared is > > irrelevant in that case. > > > > Bottom-line: ID payload in MM/pre-shared doesn't give you any usefull > > information and can not be checked for validity. So actually checking it is > > counter-productive. > > > > Unless someone can point out a fallacy in my thinking. > > > > Here's another approach: If we agree that it's valid to send ID_FQDN in > > MM/pre-shared, and you don't check this, then what do you gain by checking > > the ID payload when it's ID_IPV4? > > > > jan > > > > > Jan Vilhuber wrote: > > > > > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > > > Jan, > > > > > > > > > > You said "How would you know that I was NOT 'kivinen@iki.fi'?" > > > > > That's true - but the similar question could be asked: "How would you know > > > > > that my IP Address is NOT 204.12.57.121"? > > > > > > > > > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big > > > > difference. One selects the key, and one does not. > > > > > > > > > Both schemes have exactly the same level of insecurity (though changing IP > > > > > Address on my machine is much easier than changing the content of the ID > > > > > Payload :). > > > > > > > > > No, they don't, but I may be missing something: If you change your > > > > ip-address (barring NAT) I would pick a key based on the source-ip-address. > > > > So this does have implications. > > > > > > > > If you change the ID, nothing changes, except the string of bits that goes > > > > into the hash. There's a difference. > > > > > > > > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload > > > > > and get through the NAT and do not make the special case for not checking > > > > > ID Payload when using pre-shared key in MM. > > > > > > > > > What does checking the ID payload give you? I can't CHECK that you are > > > > 'cisco-gateway.com'. And I personally don't care if your ID payload claims > > > > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor > > > > are they particularly reliable, since you could be lying about them, and I > > > > have no way of knowing. So I ignore them, and pick the key based on > > > > source-ip-address (the only thing I CAN). > > > > > > > > > Another option in the new draft could be to remove ID Payload altogether > > > > > for MMs with pre-shared keys. > > > > > > > > > Either way, I don't get your points above. The problem is solved if you > > > > simply ignore the ID payload in this situation. Pay no attention to it. I > > > > carries no relevant information. > > > > > > > > jan > > > > > > > > > Jan Vilhuber wrote: > > > > > > > > > > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > > > > > Jan Vilhuber writes: > > > > > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > > > > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > > > > > > > > > > > For pre shared keys it doesn't offer anything. You have to know the > > > > > > > identity before ID payload anyways, because you need to select the > > > > > > > correct pre shared key before you can decrypt the ID payload. You can > > > > > > > use ID payload as a key to select correct policy for the quick mode, > > > > > > > but I don't think there is any use to require it to match the IP > > > > > > > address of the policy. This only applies for the pre shared keys. > > > > > > > > > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > > > > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > > > > > familiar with) generally have the ID field as a configuration option, I could > > > > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > > > > > How would you know that I was NOT 'kivinen@iki.fi'? > > > > > > > > > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > > > > > > should be ignored and not used for anything at all. > > > > > > > > > > > > Aggressive mode is different, since I have the option of picking the shared > > > > > > secret based on the ID, so I can use it for policy selection (or whatever). > > > > > > > > > > > > jan > > > > > > -- > > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Dec 2 20:01:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17746; Thu, 2 Dec 1999 20:01:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12931 Thu, 2 Dec 1999 21:38:24 -0500 (EST) Message-ID: <38472DD0.12D14C87@redcreek.com> Date: Thu, 02 Dec 1999 18:41:20 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bronislav Kavsan CC: Jan Vilhuber , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <38471553.93FA1EB@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bronislav Kavsan wrote: > > If your gateway is running out of memory and deleted IKE SA to free some memory - when I > want to send you keep-alive 1 min later and start IKE SA to protect it - you will have > exactly the same resource problem as you had 1 min ago. Maybe dead peer detection should not rely upon the presence of an IKE SA. Scott From owner-ipsec@lists.tislabs.com Fri Dec 3 05:13:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02432; Fri, 3 Dec 1999 05:13:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15094 Fri, 3 Dec 1999 06:48:48 -0500 (EST) Message-Id: <199912031152.GAA25657@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-dhcp-04.txt Date: Fri, 03 Dec 1999 06:52:11 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-04.txt Pages : 13 Date : 02-Dec-99 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-dhcp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991202093844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991202093844.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Dec 3 06:08:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03315; Fri, 3 Dec 1999 06:08:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15106 Fri, 3 Dec 1999 06:49:34 -0500 (EST) Message-Id: <199912031153.GAA26178@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-xauth-06.txt Date: Fri, 03 Dec 1999 06:53:03 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Authentication Within ISAKMP/Oakley (XAUTH) Author(s) : R. Pereira, S. Beaulieu Filename : draft-ietf-ipsec-isakmp-xauth-06.txt Pages : 19 Date : 02-Dec-99 This document describes a method for using existing unidirectional authentication mechanisms such as RADIUS, SecurID, and OTP within IPSec's ISAKMP protocol. The purpose of this draft is not to replace or enhance the existing authentication mechanisms described in [IKE], but rather to allow them to be extended using legacy authentication mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-xauth-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-xauth-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-isakmp-xauth-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: <19991202113118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-xauth-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-xauth-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991202113118.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Dec 3 07:20:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04288; Fri, 3 Dec 1999 07:20:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15604 Fri, 3 Dec 1999 08:43:01 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5D79@exchange> From: Tim Jenkins To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Fri, 3 Dec 1999 08:49:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan (and Tero) I have never said I counted on *receiving* a delete payload. If it appeared that I did, it was not intended. I assume I always want to *send* a delete payload. That's the basis for many of my suggestions. And that is in part because I recognize that the other end may not have the same expirations as I do. It also may not transfer its traffic to a new SA the same way I do. I might decide to terminate the SA prematurely. The transmission of deletes helps in these cases, since it at least creates a chance that the peer can figure out what's happening sooner. However, since that is optional, you're absolutely correct, we have to be able to deal with those conditions where they are not sent (or are dropped anyway.) And we do try to deal with it. I'm looking forward to a standards-based keep-alive or heartbeat or peer-viability indicator or whatever we're going to call it. The bottom line is that you treat the usage of responder-lifetime the same way I treat the *transmission* of deletes. Yet, you're right, they're both optional. And even if you do one, there are still benefits in doing the other. They aren't mutually exclusive. In any case, I've already said I'm not going to actively promote the continuous channel model anymore. I'm rewriting the re-keying document to reflect this. Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@network-alchemy.com] > Sent: December 2, 1999 4:03 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > Please re-read this after s/responder-lifetime/delete payload/g. > > How do you intend on interoperating with someone who never sends > a delete payload and doesn't process them? What will you tell > the customer? "Is one of them violating the specifications?" > > Allow me to point out that the observation "but everyone implements > the delete payload" is countered by your second statement. > > It seems to me that one can avoid all these rekeying issues by > simply implementing a very common sense feature in the protocol or > one avoid them by implementing a very complex, (let me use this term > again because I love it) Rube Goldbergian system. > > Dan. > > On Thu, 02 Dec 1999 15:30:31 EST you wrote > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > > > Sent: December 2, 1999 3:15 PM > > > To: Tim Jenkins > > > Cc: ipsec@lists.tislabs.com > > > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > > > > > > > On Thu, 02 Dec 1999 15:05:39 EST you wrote > > oo. > > > > > > I'll ask again: why wouldn't anyone use the responder-lifetime > > > notify for lifetimes which are greater than the configured value > > > and respect the lifetimes of offers which are less than the > > > configured value? > > > > The reasons are irrelevant. The simple fact is that you might > > have to interoperate with an implementation that legally doesn't > > do that. > > > > If you make the assumption that every implementation does that, > > there's a potential interoperability problem. If you don't care > > about interoperating with those implementations, then I guess > > that's your choice. But in the customer's eyes, there's a chance > > either implementation or both are going to look bad. And in > > either case, it makes IPsec look bad. > > > > (Customer: Is one violating the specifications? > > Answer: No. > > Customer: But they don't work together!!! > > Answer: Well, only under certain circumstances....) > > > > > > > > Dan. > > > > From owner-ipsec@lists.tislabs.com Fri Dec 3 08:04:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04860; Fri, 3 Dec 1999 08:04:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15523 Fri, 3 Dec 1999 08:17:12 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DCCDE762@new-exc1.ctron.com> From: "Waters, Stephen" To: "todd.glassey" Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Fri, 3 Dec 1999 13:20:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Not that I really car either, but I thought the intention was for a 'poll' to enable a client to detect when a head-end gateway had 'gone'. The poll from the head-end is not a 'keep-alive' in that it does not prevent the SAs from going necessarily. The plan we have goes like this: Client connects, and the head-end starts sending heart-beats. It continues doing this until the gateway bounces, or the gateway determines the client connection should be terminated - for whatever reason (e.g. idle timer). Ideally, the client should spot a dead gateway and try to reconnect to the same of secondary gateways. Cheers, Steve. -----Original Message----- From: todd.glassey [mailto:todd.glassey@certifiedtime.com] Sent: Thursday, December 02, 1999 6:13 PM To: Tim Jenkins Cc: Subject: Re: Heartbeats (was RE: keepalives) Tim, FYI - We use the term "heartbeat" in STime WG as a reference for the local frequency source in the Host's timebase service model. One of the things we are working on is secure timebase Steering vs. Jam Setting (ie. the maintaining of the clock accurately without violating the "boundaries of the timebase's granularity" relative to UTC). This requires both a fixed reference point for the HOST Synchronization event and the operations of the local oscillator and timebase BIOS service infrastructure. I would rather see the term Keep-Alive used to refer to the process of keeping the channel open and the session maintained, myself. Todd Glassey ----- Original Message ----- From: "Tim Jenkins" To: "Jan Vilhuber" Cc: Sent: Thursday, December 02, 1999 06:09 AM Subject: Heartbeats (was RE: keepalives) > Just a nit, but if we really mean heartbeat, can we call it that? > > A keep-alive to me is something that defeats the peer's inactivity time-out > detection mechanism, while a heartbeat is something that helps detect the > health of the peer. And a heartbeat shouldn't defeat inactivity detection, > either. > > --- > Tim Jenkins TimeStep Corporation > tjenkins@timestep.com http://www.timestep.com > (613) 599-3610 x4304 Fax: (613) 599-3617 > > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: December 1, 1999 8:55 PM > > To: Dan Harkins > > Cc: ipsec@lists.tislabs.com > > Subject: keepalives (was Re: IPSec SA DELETE in "dangling" > > implementation) > > > > > > On Wed, 1 Dec 1999, Dan Harkins wrote: > > > I think a nice generic keep alive function would be more useful to > > > implement. Why doesn't someone write a draft on this subject? > > > > > I'm sort of working myself up to it, i.e. we're still > > wondering internally > > what's best. > > > > Problem I see is that there are several different scenarios > > where different > > types of keepalives will be necessary (i.e. a dial-up > > scenario has different > > requirements than a straight ethernet scenario; ethernet > > scenario will be > > more efficient and optimizable, but dial-up is not). Once I > > get something > > written up, I'll post it to the list, but I have my doubts > > that we'll come up > > with a single sanctioned mechanism. There'll likely be at > > least two. It's > > possible we can come up with one generic enough to be used in > > both cases, but > > I doubt it (I'm a pessimist). > > > > jan > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > From owner-ipsec@lists.tislabs.com Fri Dec 3 08:40:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05505; Fri, 3 Dec 1999 08:40:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15687 Fri, 3 Dec 1999 09:00:16 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFD5D8C@exchange> From: Andrew Krywaniuk To: Jan Vilhuber , Dan Harkins Cc: Markku Savela , srao@ibondinc.com, ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Fri, 3 Dec 1999 09:06:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's probably a good idea. Change them to a MUST. My point here was that this is essentially a tragedy of the commons. Processing the peer's lifetime notify and ensuring that *his* security policy is enforced is a losing move (it provides no benefit to you and you have to spend time implementing it). But if the peer parses *my* lifetime notifies and enforces *my* security policy then I gain. The best way to solve a tragedy of the commons is to make the feature a MUST. This provides a tangible penalty for failure to cooperate (you are not standards compliant) and benefits everyone. On the other hand, processing deletes is not a tragedy of the commons. The peer has no way to determine whether you sent a delete because you detected a potential security violation or simply because you are enforcing your own SA lifetime rules, so he has a clear incentive to cooperate. Therefore, I believe that every vendor will process deletes, even if we don't make them a MUST (although there is no good reason not to). That's why I suggested that you always send the delete. When you are relying on the peer to help you enforce your security policy you have to trust them not to be malicious, but you can't assume that they will be altruistic. The fact is, enforcing this aspect of your security policy has nothing to do with what *you* implement; it's what everyone else implements that counts. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Thursday, December 02, 1999 5:58 PM > To: Dan Harkins > Cc: Markku Savela; srao@ibondinc.com; ipsec@lists.tislabs.com > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > So if both responder lifetime and delete notifications are > something anyone > in their right minds would implement, why don't we solve this > whole debate by > changing them to MUST in the new version? > > If they remain SHOULD, then you can't assume that the remote > has implemented > this. Despite it being common-sense, there's still > implementors out there > that implement the bare necessities, i.e. only the MUSTs. If > we really think > this is common-sense to implement, then what's the objection > to making thing > like that a MUST? > > jan > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > Since life times may not be same on both ends, I also > feel that we need > > > > to send Deletes to other end when IPSEC SA hard life > time expires. > > > > > > I claim: > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > (SA) > > > A ----------> B > > > > > > There is no such thing as one SA on A, and a different SA > on B. SA's > > > on both ends are just internal representation of the same logical > > > SA. They *MUST* have all parameters equal, including > lifetimes. Any > > > other situation should be considered as error or undefined state. > > > > > > I hope above will be kept in the name of predictability and > > > simplicity! > > > > Yes, me too. > > > > > If implementations want to break this "rule", they should > be prepared > > > to handle the "side effects" of the breaking without > requiring changes > > > to the other valid implementations (I guess the problem > of lifetimes > > > arises from the IKE omission that the responder does not have > > > guaranteed way to communicate to the other end that it > wants to change > > > the proposed lifetimes -- conforming implementation can > either accept > > > them as is or reject. Right?) > > > > No it can use the responder-lifetime message if it doesn't > want to accept > > the offer as is. But your absolutely right that implementations that > > break this rule suffer undesirable side effects and need some other > > mechanism like always keeping an IKE SA around, and always > sending delete > > messages, and alway assuming that the other party processes > deletes, and > > binding the IPSec SA to the IKE SA in a manner which is not > inferred by > > any of the relevant RFCs. > > > > Dan. > > > > > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ipsec@lists.tislabs.com Fri Dec 3 09:16:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05861; Fri, 3 Dec 1999 09:16:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15768 Fri, 3 Dec 1999 09:28:06 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <38470FBF.CF2E2805@ire-ma.com> References: <38470FBF.CF2E2805@ire-ma.com> Date: Fri, 3 Dec 1999 09:26:38 -0500 To: Bronislav Kavsan From: Stephen Kent Subject: Re: matching GW addr to ID payload (fwd) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I hate to jump in late to this discussion, as I may have lost the context. There is a big difference between asserting an address as an identity in the IP header, vs. asserting it in an IKE exchange, IF one uses certificates to authenticate the asserted identity in IKE. One can imagine several PKI scenarios that would enable one to have reasonable confidence in a cert issued for an address. Steve From owner-ipsec@lists.tislabs.com Fri Dec 3 09:55:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06317; Fri, 3 Dec 1999 09:55:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16178 Fri, 3 Dec 1999 11:02:08 -0500 (EST) Message-ID: <3847E9E5.4D7EB7A0@ire-ma.com> Date: Fri, 03 Dec 1999 11:03:50 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Jan Vilhuber , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <38471553.93FA1EB@ire-ma.com> <38472DD0.12D14C87@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" wrote: > Maybe dead peer detection should not rely upon the presence of an IKE > SA. I like this approach, but it needs to be further analysed: - are there any attacks possible when using unprotected NOTIFYes for keep-alive? E.g. is "false-alive" attack is really an attack? - what if protected keep-alives are used when possible (IKE SA is around) and non-protected when there is no IKE SA? - use of keep-alives in this fashion will prevent us from taking advantage of using Ack-ed NOTIFY for keep-alives, because Ack-ed NOTIFY is always protected (unless this requirement can be relaxed for keep-alives) - could resource-minded implementations when they need more memory "shrink" their SAs (instead of deleting them) to a bare minimum to only support keep-alive protection? - could we use (somehow) IPSec-based keep-alives - etc. - etc. From owner-ipsec@lists.tislabs.com Fri Dec 3 10:42:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06995; Fri, 3 Dec 1999 10:42:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16422 Fri, 3 Dec 1999 12:08:07 -0500 (EST) Date: Fri, 3 Dec 1999 11:11:06 -0600 (CST) From: Tylor Allison X-Sender: allison@stpsowk07.sctc.com To: Stephen Kent cc: Bronislav Kavsan , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Stephen Kent wrote: > I hate to jump in late to this discussion, as I may have lost the > context. There is a big difference between asserting an address as an > identity in the IP header, vs. asserting it in an IKE exchange, IF > one uses certificates to authenticate the asserted identity in IKE. > One can imagine several PKI scenarios that would enable one to have > reasonable confidence in a cert issued for an address. > > Steve This seems to be getting back to my original questions which started all this. The basis of these questions was what decisions (if any) can be made based on the source address from the IP header. For pre-shared password authentication in Main Mode, it's evident that this source IP address drives the authentication by determining which key to select. I would argue that the actual ID payload should still drive any policy decisions. Whether or not the ID payload needs to be an IPV4_ADDR which matches the source address is still unclear to me. What interests me more, however: can any decisions be made based on the packet's source IP address for cert-based policies? For instance, for signature authentication in main mode where certificates are not available online, when responding to a remote request, one needs to either assume that the remote cert is not locally available (and a certificate request must always be made), or one can use the source IP address to look up policy info for the remote host and determine if the remote cert is locally available (and if not, then send a certificate request). This must be done in the exchange prior to receiving the remote side's identity payload... since the identity payload is received in the last round of the exchange, and a certificate request cannot be made it this time, since it would extend the exchange. Along these same lines, if you set up a static VPN policy and you know what the remote IP address is, when you receive the first payload of a main mode exchange from that remote IP address, can you immediately fail the exchange if attributes in the SA payload do not match the attributes that you have set in your policy? Also, going back to Steve's message (and one of my original questions)... Given a certificate which is assigned a specific IP address (e.g. in subjectAltName extension), I think it's clear that if I use a IPV4_ADDR as the identity payload for the exchange, that it needs to match the one presented in the cert. Is anyone checking to see if this matches the source IP address from the packet? Or if I use a DN of the cert as the identity, but the cert contains the IP address, does anyone check the cert's asserted IP address with the packet? All of this then goes back to, what breaks if there can be multiple IP addresses associated with the remote host (e.g. aliased addresses for the interface, or multiple interfaces). This clearly breaks the pre-shared key case (unless you set the same key for each of the aliased addresses). If vendors are using the source IP address for other purposes (initial policy checks, cert lookup, etc.), this may break other authentication methods as well. I know this isn't a very likely occurance, but it is still a concert for us. I'm just wondering if other vendors out there have addressed this issue, and can provide any insight on how they plan to handle it. Thanks! Tylor --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-ipsec@lists.tislabs.com Fri Dec 3 10:56:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07228; Fri, 3 Dec 1999 10:56:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16388 Fri, 3 Dec 1999 12:01:32 -0500 (EST) From: "Scott Fanning" To: "Andrew Krywaniuk" , "Jan Vilhuber" , "Dan Harkins" Cc: "Markku Savela" , , Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Fri, 3 Dec 1999 09:03:39 -0800 Message-ID: <000e01bf3db0$58463dc0$ab2647ab@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <319A1C5F94C8D11192DE00805FBBADDFFD5D8C@exchange> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew As long as there is no guarantee of delivery of the DELETE notification, we still have to handle the case were there is no delete. I agree that the attempt must be made though. Scott > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk > Sent: Friday, December 03, 1999 6:06 AM > To: Jan Vilhuber; Dan Harkins > Cc: Markku Savela; srao@ibondinc.com; ipsec@lists.tislabs.com > Subject: RE: IPSec SA DELETE in "dangling" implementation > > > That's probably a good idea. Change them to a MUST. > > > > My point here was that this is essentially a tragedy of the commons. > Processing the peer's lifetime notify and ensuring that *his* security > policy is enforced is a losing move (it provides no benefit to you and you > have to spend time implementing it). But if the peer parses *my* lifetime > notifies and enforces *my* security policy then I gain. > > The best way to solve a tragedy of the commons is to make the feature a > MUST. This provides a tangible penalty for failure to cooperate > (you are not > standards compliant) and benefits everyone. > > On the other hand, processing deletes is not a tragedy of the commons. The > peer has no way to determine whether you sent a delete because > you detected > a potential security violation or simply because you are > enforcing your own > SA lifetime rules, so he has a clear incentive to cooperate. Therefore, I > believe that every vendor will process deletes, even if we don't > make them a > MUST (although there is no good reason not to). > > That's why I suggested that you always send the delete. When you > are relying > on the peer to help you enforce your security policy you have to > trust them > not to be malicious, but you can't assume that they will be > altruistic. The > fact is, enforcing this aspect of your security policy has nothing to do > with what *you* implement; it's what everyone else implements that counts. > > > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Thursday, December 02, 1999 5:58 PM > > To: Dan Harkins > > Cc: Markku Savela; srao@ibondinc.com; ipsec@lists.tislabs.com > > Subject: Re: IPSec SA DELETE in "dangling" implementation > > > > > > So if both responder lifetime and delete notifications are > > something anyone > > in their right minds would implement, why don't we solve this > > whole debate by > > changing them to MUST in the new version? > > > > If they remain SHOULD, then you can't assume that the remote > > has implemented > > this. Despite it being common-sense, there's still > > implementors out there > > that implement the bare necessities, i.e. only the MUSTs. If > > we really think > > this is common-sense to implement, then what's the objection > > to making thing > > like that a MUST? > > > > jan > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > Since life times may not be same on both ends, I also > > feel that we need > > > > > to send Deletes to other end when IPSEC SA hard life > > time expires. > > > > > > > > I claim: > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > (SA) > > > > A ----------> B > > > > > > > > There is no such thing as one SA on A, and a different SA > > on B. SA's > > > > on both ends are just internal representation of the same logical > > > > SA. They *MUST* have all parameters equal, including > > lifetimes. Any > > > > other situation should be considered as error or undefined state. > > > > > > > > I hope above will be kept in the name of predictability and > > > > simplicity! > > > > > > Yes, me too. > > > > > > > If implementations want to break this "rule", they should > > be prepared > > > > to handle the "side effects" of the breaking without > > requiring changes > > > > to the other valid implementations (I guess the problem > > of lifetimes > > > > arises from the IKE omission that the responder does not have > > > > guaranteed way to communicate to the other end that it > > wants to change > > > > the proposed lifetimes -- conforming implementation can > > either accept > > > > them as is or reject. Right?) > > > > > > No it can use the responder-lifetime message if it doesn't > > want to accept > > > the offer as is. But your absolutely right that implementations that > > > break this rule suffer undesirable side effects and need some other > > > mechanism like always keeping an IKE SA around, and always > > sending delete > > > messages, and alway assuming that the other party processes > > deletes, and > > > binding the IPSec SA to the IKE SA in a manner which is not > > inferred by > > > any of the relevant RFCs. > > > > > > Dan. > > > > > > > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > From owner-ipsec@lists.tislabs.com Fri Dec 3 11:55:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07883; Fri, 3 Dec 1999 11:55:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16663 Fri, 3 Dec 1999 13:10:34 -0500 (EST) Date: Fri, 3 Dec 1999 10:13:25 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Stephen Kent cc: Bronislav Kavsan , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The NAT scenario being discussed here is: Initiator----------NAT device---------------Responder srcIP=ID=IP1 ID=IP1 ID=IP1 srcIP=IP2 srcIP=IP2 An intermediate device has changed the srcIP address from IP1 to IP2, and the responder uses the changed IP address, to search the pre-shared key, and ignore the ID which is unchanged, and also protected. This only works for static NAT, and does not work Dynamic for NAT, or NAT overload. The initiator is trying to autenticate to the responder using ID=SrcIP=IP1, but the resoponder is authenticating the initiator as SrcIP=IP2. Is this acceptable, or should we enforce that ID and the IP address used should be equal? TIA, chinna On Fri, 3 Dec 1999, Stephen Kent wrote: > I hate to jump in late to this discussion, as I may have lost the > context. There is a big difference between asserting an address as an > identity in the IP header, vs. asserting it in an IKE exchange, IF > one uses certificates to authenticate the asserted identity in IKE. > One can imagine several PKI scenarios that would enable one to have > reasonable confidence in a cert issued for an address. > > Steve > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Dec 3 12:09:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08045; Fri, 3 Dec 1999 12:09:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16745 Fri, 3 Dec 1999 13:29:29 -0500 (EST) Message-ID: <38480C53.D3D8FC42@ire-ma.com> Date: Fri, 03 Dec 1999 13:30:43 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "CHINNA N.R. PELLACURU" CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "CHINNA N.R. PELLACURU" wrote: > Is this acceptable, or should we enforce that ID and the IP address used > should be equal? I would say yes in the case when ID Payload contains IP Address type. But we should also allow to have ID Payload to contain FQDN type (and other non-IP IDs) and is use it to select the Policy entry. From owner-ipsec@lists.tislabs.com Fri Dec 3 12:41:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08591; Fri, 3 Dec 1999 12:41:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16813 Fri, 3 Dec 1999 13:44:26 -0500 (EST) Message-ID: <3847B6BB.6A236690@blr.vsnl.net.in> Date: Fri, 03 Dec 1999 17:55:31 +0530 From: comp6 X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: bkavsan@ire-ma.com CC: ipsec@lists.tislabs.com Subject: IPSEC SA DELETE in "dangling" implementations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan wrote: > Here is the dilemma: if "dangling" implementation wants to send IPSec SA > DELETE message, while the "parent" IKE SA is no longer there (expired or > deleted), the alternatives are (and I do not like either of them): > a) do not send DELETE > b) re-negotiate IKE SA before sending DELETE > Any suggestions? A third option is to design a oneway authenticated message (proofed against replay attacks). Such oneway authenticated message can be used for 'delete', 'invalid spi' and other notifications. If such a design is possible then it is not necessary to establish IKE SA to send a 'delete' notification. The oneway message could be authenticated using a signatures or hash generated using preshared secret, could include the id payload to allow the peer to identify the matching shared secret in the case of the pre-shared secret. The oneway message could also use as part of the hash information from the event causing the notification to be generated. This could prevent replay attacks. Any thoughts on this? From owner-ipsec@lists.tislabs.com Fri Dec 3 12:46:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08640; Fri, 3 Dec 1999 12:46:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16945 Fri, 3 Dec 1999 14:04:31 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 11:07:28 -0800 (PST) From: Jan Vilhuber To: Slava Kavsan cc: "Scott G. Kelly" , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <3847E9E5.4D7EB7A0@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Slava Kavsan wrote: > "Scott G. Kelly" wrote: > > > Maybe dead peer detection should not rely upon the presence of an IKE > > SA. > > I like this approach, but it needs to be further analysed: > > - are there any attacks possible when using unprotected NOTIFYes for > keep-alive? E.g. is "false-alive" attack is really an attack? It certainly is an attack. Whether you believe it is not serious enough to protect against is another question, but it certainly is an attack. > - what if protected keep-alives are used when possible (IKE SA is around) > and non-protected when there is no IKE SA? Then what's the point? If you go with unprotected keepalives later, why even bother going with protected keepalives to begin with? In which case we go back to your first point. > - use of keep-alives in this fashion will prevent us from taking advantage > of using Ack-ed NOTIFY for keep-alives, because Ack-ed NOTIFY is always > protected (unless this requirement can be relaxed for keep-alives) > - could resource-minded implementations when they need more memory "shrink" > their SAs (instead of deleting them) to a bare minimum to only support > keep-alive protection? > - could we use (somehow) IPSec-based keep-alives You could, but it would introduce a 'special' ipsec packet, which I do not particularly care for. IPSEC shouldn't have to look at each packet and decide if this is a 'control packet' or if this is a regular packet. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 12:47:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08679; Fri, 3 Dec 1999 12:47:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16924 Fri, 3 Dec 1999 14:01:56 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 11:04:38 -0800 (PST) From: Jan Vilhuber To: "Scott G. Kelly" cc: Bronislav Kavsan , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <38472DD0.12D14C87@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Scott G. Kelly wrote: > Bronislav Kavsan wrote: > > > > If your gateway is running out of memory and deleted IKE SA to free some memory - when I > > want to send you keep-alive 1 min later and start IKE SA to protect it - you will have > > exactly the same resource problem as you had 1 min ago. > > Maybe dead peer detection should not rely upon the presence of an IKE > SA. > How would you do this? Through the IPSEC SA? That would run up (possibly) the packet/byte counts, which is not a good thing, if you want to account for packets/bytes to charge customers. Are you suggesting sending un-authenticated keepalives? What about having someone spoof the 'upness' of a remote box? Does this bother anyone (it does bother me). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 12:49:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08704; Fri, 3 Dec 1999 12:49:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16827 Fri, 3 Dec 1999 13:44:53 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 10:47:55 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <38471553.93FA1EB@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > If your gateway is running out of memory and deleted IKE SA to free some memory - when I > want to send you keep-alive 1 min later and start IKE SA to protect it - you will have > exactly the same resource problem as you had 1 min ago. > Yes, but this time you have good reason, whereas before you didn't. jan > Jan Vilhuber wrote: > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > > > You missed to read very first words in my mail - "Apart from resource management > > > concerns.....". > > > > > Well, yes, but resource concerns are driving at least part of this > > discussion. They are a large concern. If we agree that there may be resource > > concerns, then what's the point of the rest of your email? It's not like you > > (the peer) can distinguish whether I deleted my SA because I felt like it, or > > because or resource concerns. All YOU see is that I deleted it. So why do you > > feel the need to continue and state that you want the option to rekey > > immediately ANYWAY? You can't tell, so don't do it. > > > > jan > > > > > Jan Vilhuber wrote: > > > > > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > > > Apart from resource management concerns I do not see any drawbacks for re-keying > > > > > IKE SA immediately after it is expired or deleted (assuming that there are active > > > > > IPSec SA existed under old IKE SA). > > > > > > > > > > But, I think, this scheme schould not me mandated by the standards - it should be > > > > > left to individual implementations or policies. > > > > > > > > Yes and no. As Tero pointed out (or was it Dan? I forget) if someone deleted > > > > their IKE SA for resource-recovery reasons (short of memory.. whatever) > > > > you're REALLY not doing them a favor by rekeying immediately. > > > > > > > > One might almost argue that we should add verbiage to the rfc that says > > > > something like "MUST not rekey unless the SA is really needed" (for some > > > > definition of 'really needed'). > > > > > > > > jan > > > > > > > > > The benefits of such logic will be ability to send protected Informational > > > > > Exchanges at ALL times, including protected keep-alives and DELETEs. > > > > > > > > > > Srinivasa Rao Addepalli wrote: > > > > > > > > > > > Jan Vilhuber wrote: > > > > > > > > > > > > > So if both responder lifetime and delete notifications are something anyone > > > > > > > in their right minds would implement, why don't we solve this whole debate by > > > > > > > changing them to MUST in the new version? > > > > > > > > > > > > > > If they remain SHOULD, then you can't assume that the remote has implemented > > > > > > > this. Despite it being common-sense, there's still implementors out there > > > > > > > that implement the bare necessities, i.e. only the MUSTs. If we really think > > > > > > > this is common-sense to implement, then what's the objection to making thing > > > > > > > like that a MUST? > > > > > > > > > > > > > > jan > > > > > > > > > > > > Yes. I agree with you and make it MUST to remove any ambiguities. > > > > > > > > > > > > Regards > > > > > > Srini > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 1999, Dan Harkins wrote: > > > > > > > > > > > > > > > On Thu, 02 Dec 1999 22:33:56 +0200 you wrote > > > > > > > > > > > > > > > > > > > Since life times may not be same on both ends, I also feel that we need > > > > > > > > > > to send Deletes to other end when IPSEC SA hard life time expires. > > > > > > > > > > > > > > > > > > I claim: > > > > > > > > > > > > > > > > > > An IPSEC SA is a unidirectional entity between two end points: > > > > > > > > > > > > > > > > > > (SA) > > > > > > > > > A ----------> B > > > > > > > > > > > > > > > > > > There is no such thing as one SA on A, and a different SA on B. SA's > > > > > > > > > on both ends are just internal representation of the same logical > > > > > > > > > SA. They *MUST* have all parameters equal, including lifetimes. Any > > > > > > > > > other situation should be considered as error or undefined state. > > > > > > > > > > > > > > > > > > I hope above will be kept in the name of predictability and > > > > > > > > > simplicity! > > > > > > > > > > > > > > > > Yes, me too. > > > > > > > > > > > > > > > > > If implementations want to break this "rule", they should be prepared > > > > > > > > > to handle the "side effects" of the breaking without requiring changes > > > > > > > > > to the other valid implementations (I guess the problem of lifetimes > > > > > > > > > arises from the IKE omission that the responder does not have > > > > > > > > > guaranteed way to communicate to the other end that it wants to change > > > > > > > > > the proposed lifetimes -- conforming implementation can either accept > > > > > > > > > them as is or reject. Right?) > > > > > > > > > > > > > > > > No it can use the responder-lifetime message if it doesn't want to accept > > > > > > > > the offer as is. But your absolutely right that implementations that > > > > > > > > break this rule suffer undesirable side effects and need some other > > > > > > > > mechanism like always keeping an IKE SA around, and always sending delete > > > > > > > > messages, and alway assuming that the other party processes deletes, and > > > > > > > > binding the IPSec SA to the IKE SA in a manner which is not inferred by > > > > > > > > any of the relevant RFCs. > > > > > > > > > > > > > > > > Dan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 12:49:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08720; Fri, 3 Dec 1999 12:49:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16968 Fri, 3 Dec 1999 14:07:37 -0500 (EST) Message-ID: <384815A8.479DAEDF@redcreek.com> Date: Fri, 03 Dec 1999 11:10:32 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: Jan Vilhuber , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <38471553.93FA1EB@ire-ma.com> <38472DD0.12D14C87@redcreek.com> <3847E9E5.4D7EB7A0@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What I should have said was, maybe dead peer detection should not rely upon IKE. That is, maybe IKE is the wrong vehicle. Slava Kavsan wrote: > > "Scott G. Kelly" wrote: > > > Maybe dead peer detection should not rely upon the presence of an IKE > > SA. > > I like this approach, but it needs to be further analysed: > > - are there any attacks possible when using unprotected NOTIFYes for keep-alive? E.g. is > "false-alive" attack is really an attack? > - what if protected keep-alives are used when possible (IKE SA is around) and non-protected > when there is no IKE SA? > - use of keep-alives in this fashion will prevent us from taking advantage of using Ack-ed > NOTIFY for keep-alives, because Ack-ed NOTIFY is always protected (unless this requirement can > be relaxed for keep-alives) > - could resource-minded implementations when they need more memory "shrink" their SAs (instead > of deleting them) to a bare minimum to only support keep-alive protection? > - could we use (somehow) IPSec-based keep-alives > - etc. > - etc. Slava Kavsan wrote: > > "Scott G. Kelly" wrote: > > > Maybe dead peer detection should not rely upon the presence of an IKE > > SA. > > I like this approach, but it needs to be further analysed: > > - are there any attacks possible when using unprotected NOTIFYes for keep-alive? E.g. is > "false-alive" attack is really an attack? > - what if protected keep-alives are used when possible (IKE SA is around) and non-protected > when there is no IKE SA? > - use of keep-alives in this fashion will prevent us from taking advantage of using Ack-ed > NOTIFY for keep-alives, because Ack-ed NOTIFY is always protected (unless this requirement can > be relaxed for keep-alives) > - could resource-minded implementations when they need more memory "shrink" their SAs (instead > of deleting them) to a bare minimum to only support keep-alive protection? > - could we use (somehow) IPSec-based keep-alives > - etc. > - etc. From owner-ipsec@lists.tislabs.com Fri Dec 3 12:53:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08758; Fri, 3 Dec 1999 12:53:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16870 Fri, 3 Dec 1999 13:47:35 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 10:50:31 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <38471824.DDC60425@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > Ooops - you are right - can't select the key based on ID Payload. But can verify that the > policy entry selected based on source-ip-address is the same as pointed out by ID Payload. > Yes, but again, what's the point? If you pick the policy based on ID after making sure the ID is the same as the source-ip-address, you've effectively picked the policy based on the source-ip-address. The ID didn't really enter into the picture. If you have ID_FQDN, you couldn't do this check at all, and you would again only pick the policy based on the source-ip-address, since that's the only authenticated piece of information you have. So in either case, the ID payload is irrelevant. While checking it when you CAN is not illegal per the rfc, it's also quite useless, and makes your implementation NOT work through NAT. jan > Bronislav Kavsan wrote: > > > Jan Vilhuber wrote: > > > > > Huh? If using MM with pre-shared keys, you can't use the ID payload to select > > > the key. > > > > Why not if I am a responder? How it is different from using source-ip-adress to select the > > key? > > > > > (I seem to recall you > > > saying it's a one-liner). > > > > Yeah.....it takes one line of code, but requires whole new Release and upgrading thousands > > of installations... > > > > > Whether or not we rewrite the rfc to exclude the ID from MM/pre-shared is > > > irrelevant in that case. > > > > > > Bottom-line: ID payload in MM/pre-shared doesn't give you any usefull > > > information and can not be checked for validity. So actually checking it is > > > counter-productive. > > > > > > Unless someone can point out a fallacy in my thinking. > > > > > > Here's another approach: If we agree that it's valid to send ID_FQDN in > > > MM/pre-shared, and you don't check this, then what do you gain by checking > > > the ID payload when it's ID_IPV4? > > > > > > jan > > > > > > > Jan Vilhuber wrote: > > > > > > > > > On Thu, 2 Dec 1999, Bronislav Kavsan wrote: > > > > > > Jan, > > > > > > > > > > > > You said "How would you know that I was NOT 'kivinen@iki.fi'?" > > > > > > That's true - but the similar question could be asked: "How would you know > > > > > > that my IP Address is NOT 204.12.57.121"? > > > > > > > > > > > Do you mean ip-address as in 'source-ip-address' or 'ID_IPV4'? There's a big > > > > > difference. One selects the key, and one does not. > > > > > > > > > > > Both schemes have exactly the same level of insecurity (though changing IP > > > > > > Address on my machine is much easier than changing the content of the ID > > > > > > Payload :). > > > > > > > > > > > No, they don't, but I may be missing something: If you change your > > > > > ip-address (barring NAT) I would pick a key based on the source-ip-address. > > > > > So this does have implications. > > > > > > > > > > If you change the ID, nothing changes, except the string of bits that goes > > > > > into the hash. There's a difference. > > > > > > > > > > > But at least using "cisco-gateway.com" allows me to ALWAYS check ID Payload > > > > > > and get through the NAT and do not make the special case for not checking > > > > > > ID Payload when using pre-shared key in MM. > > > > > > > > > > > What does checking the ID payload give you? I can't CHECK that you are > > > > > 'cisco-gateway.com'. And I personally don't care if your ID payload claims > > > > > you are 1.1.1.1. Neither pieces of information enlighten me in any way, nor > > > > > are they particularly reliable, since you could be lying about them, and I > > > > > have no way of knowing. So I ignore them, and pick the key based on > > > > > source-ip-address (the only thing I CAN). > > > > > > > > > > > Another option in the new draft could be to remove ID Payload altogether > > > > > > for MMs with pre-shared keys. > > > > > > > > > > > Either way, I don't get your points above. The problem is solved if you > > > > > simply ignore the ID payload in this situation. Pay no attention to it. I > > > > > carries no relevant information. > > > > > > > > > > jan > > > > > > > > > > > Jan Vilhuber wrote: > > > > > > > > > > > > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > > > > > > Jan Vilhuber writes: > > > > > > > > > I would argue that it doesn't and that you can safely ignore the ID payload > > > > > > > > > in the MM/pre-shared scenario, since it adds no value anyway. > > > > > > > > > > > > > > > > For pre shared keys it doesn't offer anything. You have to know the > > > > > > > > identity before ID payload anyways, because you need to select the > > > > > > > > correct pre shared key before you can decrypt the ID payload. You can > > > > > > > > use ID payload as a key to select correct policy for the quick mode, > > > > > > > > but I don't think there is any use to require it to match the IP > > > > > > > > address of the policy. This only applies for the pre shared keys. > > > > > > > > > > > > > > But if you don't 'authenticate' the ID payload in any way, I would think it's > > > > > > > insecure to select policy with it. Since PC-clients (or at least the one I'm > > > > > > > familiar with) generally have the ID field as a configuration option, I could > > > > > > > put in an ID of 'kivinen@iki.fi'. Would you then use this to select policy? > > > > > > > How would you know that I was NOT 'kivinen@iki.fi'? > > > > > > > > > > > > > > Personally, I feel the ID in MM/pre-shared is pretty much superfluous and > > > > > > > should be ignored and not used for anything at all. > > > > > > > > > > > > > > Aggressive mode is different, since I have the option of picking the shared > > > > > > > secret based on the ID, so I can use it for policy selection (or whatever). > > > > > > > > > > > > > > jan > > > > > > > -- > > > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 13:01:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08997; Fri, 3 Dec 1999 13:01:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16938 Fri, 3 Dec 1999 14:04:11 -0500 (EST) Date: Fri, 3 Dec 1999 11:07:09 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Slava Kavsan cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <38480C53.D3D8FC42@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Slava Kavsan wrote: > "CHINNA N.R. PELLACURU" wrote: > > > Is this acceptable, or should we enforce that ID and the IP address used > > should be equal? > > I would say yes in the case when ID Payload contains IP Address type. > But we should also allow to have ID Payload to contain FQDN type (and other > non-IP IDs) and is use it to select the Policy entry. > > > If you do not check that the ID used to search the pre-shared key is the same as the ID payload content, then you should not use the ID payload content to select policy. IE, in MM using pre-shared keys, only the source IP address on the negotiation can be used to select policy. If I know the pre-shared key associated with IP1, then the gateway should select the policy associated with IP1, and should not select the policy based on what I sent in the ID payload (if this is different from IP1). -chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Dec 3 13:31:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09288; Fri, 3 Dec 1999 13:31:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17043 Fri, 3 Dec 1999 14:31:24 -0500 (EST) Message-ID: <38481B49.A93E23F9@redcreek.com> Date: Fri, 03 Dec 1999 11:34:33 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: Re: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt References: <199911191158.GAA16457@ietf.org> <38446DE8.6074AEF8@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet wrote: > > Howdy () > > I would like to develop feed back on your draft. I believe it is an > important problem. But just so I don't get lost chasing rabbits, first I > would ask the authors to provide their definitions for: > > * IPsec traffic flows > * IPsec tunnels > * IKE tunnel > > -- > #################################### > # Ricky Charlet > # (510) 795-6903 > # rcharlet@redcreek.com > #################################### > > end Howdy; Howdy () I have not heard from anyone yet. I am still seeking clarification on these flow-mib deffinitions. Let my offer my guess as to that the definitions *might* be: * IPsec traffic flows guess1: the set of packets which match as to outer IP header. guess2: the set of packets which match against a selector. * IPsec tunnels The set of inbound and outbound SAs instantiated by a particular selector over all time iregardless of how often the SAs were re-keyed or how often the SAs were deleted and re-initiated. * IKE tunnel The set of SAs matching as to peer, authMethod, and authData over all time iregardless of how often the SAs were re-keyed or how often the SAs were deleted and re-initiated. Some things I wonder are: 1. What if traffic from different selectors travels over the same IPsec SA. Is that the same IPsec tunnel? 2. What if my inbound and outbound selectors are a-symetric. Does that interfere with defining a VPN tunnel? 3. Do you intend to tread 'dial-up' metaphore tunnles any differently than 'nailed-up' metaphore tunnels? Authors please comment. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Fri Dec 3 13:33:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09365; Fri, 3 Dec 1999 13:33:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17063 Fri, 3 Dec 1999 14:32:36 -0500 (EST) Message-Id: <199912031933.LAA19648@potassium.network-alchemy.com> To: comp6 cc: bkavsan@ire-ma.com, ipsec@lists.tislabs.com Subject: Re: IPSEC SA DELETE in "dangling" implementations In-reply-to: Your message of "Fri, 03 Dec 1999 17:55:31 +0530." <3847B6BB.6A236690@blr.vsnl.net.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19645.944249604.1@network-alchemy.com> Date: Fri, 03 Dec 1999 11:33:25 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This sounds like the In-Line ISAKMP work that was abandoned a while ago. Perhaps we should revisit this. An in-line ISAKMP message could solve this issue and an also the keepalive problem (also we might want to consider reserving a SPI for this purpose too to avoid having to rely on IKE). That was one of the nice things about SKIP. Dan. On Fri, 03 Dec 1999 17:55:31 +0530 you wrote > Slava Kavsan wrote: > > > Here is the dilemma: if "dangling" implementation wants to send IPSec > SA > > DELETE message, while the "parent" IKE SA is no longer there (expired > or > > deleted), the alternatives are (and I do not like either of them): > > > a) do not send DELETE > > b) re-negotiate IKE SA before sending DELETE > > > Any suggestions? > A third option is to design a oneway authenticated message > (proofed against replay attacks). Such oneway authenticated message > can be used for 'delete', 'invalid spi' and other notifications. > If such a design is possible then it is not necessary to establish > IKE SA to send a 'delete' notification. > > The oneway message could be authenticated using a signatures > or hash generated using preshared secret, could include the > id payload to allow the peer to identify the matching shared > secret in the case of the pre-shared secret. The oneway message > could also use as part of the hash information from the event > causing the notification to be generated. This could prevent > replay attacks. > > Any thoughts on this? > > > > > From owner-ipsec@lists.tislabs.com Fri Dec 3 13:39:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09398; Fri, 3 Dec 1999 13:38:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17033 Fri, 3 Dec 1999 14:29:10 -0500 (EST) Date: Fri, 3 Dec 1999 21:32:29 +0200 (EET) Message-Id: <199912031932.VAA00262@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jan Vilhuber Cc: Slava Kavsan , "Scott G. Kelly" , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: References: <3847E9E5.4D7EB7A0@ire-ma.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > > - could we use (somehow) IPSec-based keep-alives > You could, but it would introduce a 'special' ipsec packet, which I do not > particularly care for. IPSEC shouldn't have to look at each packet and decide > if this is a 'control packet' or if this is a regular packet. We already have that "special" packet. It is called ICMP echo (ping)... I don't think there is need to create another one. If we use IPsec based keep-alives, I think it should use normal ICMP echo (ping) packets. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Dec 3 14:19:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09938; Fri, 3 Dec 1999 14:19:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17270 Fri, 3 Dec 1999 15:22:58 -0500 (EST) Message-ID: <384826CC.73979B0C@ire-ma.com> Date: Fri, 03 Dec 1999 15:23:40 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "CHINNA N.R. PELLACURU" CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well... in this case neither my scheme nor Jan's scheme are going to work with NAT. Unless users are willing to switch to alternatives like Aggressive Mode or Certificate-based authentication, NAT users will be out of luck :(( . "CHINNA N.R. PELLACURU" wrote: > On Fri, 3 Dec 1999, Slava Kavsan wrote: > > > "CHINNA N.R. PELLACURU" wrote: > > > > > Is this acceptable, or should we enforce that ID and the IP address used > > > should be equal? > > > > I would say yes in the case when ID Payload contains IP Address type. > > But we should also allow to have ID Payload to contain FQDN type (and other > > non-IP IDs) and is use it to select the Policy entry. > > > > > > > > If you do not check that the ID used to search the pre-shared key is the > same as the ID payload content, then you should not use the ID payload > content to select policy. IE, in MM using pre-shared keys, only the source > IP address on the negotiation can be used to select policy. > > If I know the pre-shared key associated with IP1, then the gateway should > select the policy associated with IP1, and should not select the policy > based on what I sent in the ID payload (if this is different from IP1). > > -chinna > > chinna narasimha reddy pellacuru > s/w engineer -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Dec 3 15:08:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10596; Fri, 3 Dec 1999 15:08:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17480 Fri, 3 Dec 1999 16:26:09 -0500 (EST) Date: Fri, 3 Dec 1999 23:29:39 +0200 (EET) Message-Id: <199912032129.XAA23132@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912032105.QAA22208@tonga.xedia.com> References: <3847E9E5.4D7EB7A0@ire-ma.com> <199912031932.VAA00262@torni.ssh.fi> <199912032105.QAA22208@tonga.xedia.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > I don't think that works in general. What would you ping? The > security gateway? The host I want to check, i.e. normally the gateway. > But the security policy for the SA may not have that address as an > allowed (inner) address. If I enable that kind of keep-alive, then it must be allowed, i.e. I must make sure that the policy allows me to send packets to gw if I want to use ping based keep-alive mechanism. I think adding one policy rule is much easier, than making special IKE notifications or something like that... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Dec 3 15:08:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10608; Fri, 3 Dec 1999 15:08:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17433 Fri, 3 Dec 1999 16:09:12 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Fri, 3 Dec 1999 16:15:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How about, to get this discussion going, I suggest a format and you (the list) tell me if it seems appropriate. I can put this in a draft if there is interest in standardization. I think that different types of heartbeats (phase 1/phase 2, SA-referenced/host-referenced) provide different services, and we need to support all kinds. I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then search & replace with your favorite term. When I do refer to keep-alives at the end of the document, I use Tim's definition (a mechanism for disabling the peer's inactivity timeout). ---------------------------------------------------------------------------- As I see it, there are two types of heartbeats: phase 1 heartbeats and phase 2 heartbeats. PHASE 1 HEARTBEATS: Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they also tell you that the peer is still there. However, this is a sufficient but not necessary condition. The peer may be a dangling implementation, in which case they may not send phase 1 heartbeats even though they are still running. However, phase 1 heartbeats still have a use because they ensure that the peers will always agree on whether a phase 1 exists. It avoids the clumsiness of one peer trying to send a message on the phase 1, receiving NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase 1 is down and needs to be rekeyed. Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as a means of determining when an SA has gone down is vulnerable to DoS attacks, whereas heartbeats are not. I'm not going to discuss a format for phase 1 heartbeats in this post because IMHO it's not a technically difficult issue. Any one of a million packet formats would suffice (info mode, config mode, acknowledged info mode, some new exchange) and the only real issue is getting a group of people to settle on any particular one. PHASE 2 HEARTBEATS: There are two types of phase 2 heartbeats: host-referenced and SA-referenced. A host-referenced heartbeat is a protocol that runs across a dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a protocol that runs across an existing (user) SA. Host-referenced heartbeats can only be used to detect if the peer is still up and running. Therefore, they are of limited use. (However, the fact that they don't carry any sensitive information means that they they would never need to be deleted before their natural lifetime. Therefore, they would be the most reliable means of detecting if the peer is still alive since there is no possibility of a phase 2 delete being lost.) SA-referenced heartbeats detect if a specific phase 2 SA is still working. They also probably tell you when the peer is not there, since you wouldn't expect a phase 2 SA to disappear without receiving a delete (although I've been hearing some discussion of this recently on the list). However, they are probably the most useful type of heartbeat, which is why I am going to discuss them here. SA-referenced Phase 2 heartbeats are more technically complicated than other heartbeats because: 1) They must not interfere with the peer's inactivity timeouts. 2) They must not disturb any accounting services that may be running. 3) They must not result in any packets ending up on the peer's red network. 4) They must not assume that a phase 1 SA exists between the two peers. It is not, in general, possible to satisfy all of these constraints without some degree of cooperation. Therefore, both peers must be aware of the heartbeat scheme that is being used (i.e. it must be negotiated). In light of these constraints, I propose the following format: Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 and peer 2 replies. In order to distinguish these pings from user traffic, the source and destinations addresses are set to the hosts' black IPs. If either side fails to receive a heartbeat within N*X seconds then they can assume that the SA has gone down (and they should send a delete for it). (If they fail to receive a ping but they receive other traffic on the SA then something has gone wrong and they should log the event). Replay protection is not required, as IPSec automatically provides it. It is not necessary for peer 2 to ever initiate the pings. However, to increase reliability, if peer 2 does not receive a ping during the normal window [X, X*3/2], he may force the issue by initiating a ping in the opposite direction. This technique has the following advantages: 1) It satisfies all of the above constraints. 2) It does not require the host to have any knowledge of the peer's red IP or red subnet. 3) Ping has universal brand-name recognition as a heartbeat protocol. Therefore, no special payload format is required. and the following disadvantages: 1) The SPD must make a specific exception for ping packets between the black IPs. 2) The accounting service should know not to bill the user for this traffic. However, I believe these disadvantages will be inherent in any SA-referenced heartbeat scheme. Note that a Host-referenced heartbeat scheme could be constructed in the same way as an SA-referenced scheme, simply by negotiating a dedicated SA using the black IPs as the endpoints. This could be done in tunnel mode (presumably using the same policy exception that is used for SA-referenced heartbeats) or it could simply be done in transport mode. FUTURE CONSIDERATIONS: One potential limitation of this scheme is that it does not generalize well to keep-alives. The use of ping as a packet format is simple, but it doesn't allow us to specify any additional information (all it says is STILL_CONNECTED). It may be desirable to send extra information in the packet. For example, a simple keep-alive (in the literal sense) scheme would be to take the heartbeat scheme and add one extra bit of information (E.g. STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer that idle timeouts be disabled via. a negotiated attribute of the SA (if feature negotiation ever gets standardized). There is no particular reason to use ping as transport, except for the fact that it is already a universally accepted packet format and requires no approval from IANA. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Fri Dec 3 15:14:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10670; Fri, 3 Dec 1999 15:14:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17407 Fri, 3 Dec 1999 16:02:17 -0500 (EST) Date: Fri, 3 Dec 1999 16:05:41 -0500 Message-Id: <199912032105.QAA22208@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kivinen@ssh.fi Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3847E9E5.4D7EB7A0@ire-ma.com> <199912031932.VAA00262@torni.ssh.fi> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> Jan Vilhuber writes: >> > - could we use (somehow) IPSec-based keep-alives You could, but >> it would introduce a 'special' ipsec packet, which I do not >> particularly care for. IPSEC shouldn't have to look at each packet >> and decide if this is a 'control packet' or if this is a regular >> packet. Tero> We already have that "special" packet. It is called ICMP echo Tero> (ping)... I don't think there is need to create another one. If Tero> we use IPsec based keep-alives, I think it should use normal Tero> ICMP echo (ping) packets. I don't think that works in general. What would you ping? The security gateway? But the security policy for the SA may not have that address as an allowed (inner) address. Some random address behind the security gateway? But you can't in general pick one and know that it will be up. paul From owner-ipsec@lists.tislabs.com Fri Dec 3 15:18:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10719; Fri, 3 Dec 1999 15:18:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17521 Fri, 3 Dec 1999 16:34:46 -0500 (EST) Date: Fri, 3 Dec 1999 16:38:12 -0500 Message-Id: <199912032138.QAA22709@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kivinen@ssh.fi Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <3847E9E5.4D7EB7A0@ire-ma.com> <199912031932.VAA00262@torni.ssh.fi> <199912032105.QAA22208@tonga.xedia.com> <199912032129.XAA23132@torni.ssh.fi> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> Paul Koning writes: >> I don't think that works in general. What would you ping? The >> security gateway? Tero> The host I want to check, i.e. normally the gateway. >> But the security policy for the SA may not have that address as an >> allowed (inner) address. Tero> If I enable that kind of keep-alive, then it must be allowed, Tero> i.e. I must make sure that the policy allows me to send packets Tero> to gw if I want to use ping based keep-alive mechanism. Yes, that would be the consequence. But that's not a good thing at all. There are clear security benefits to having a tunnel whose users have no ability to talk to the security gateway itself. Disallowing such policies for the sake of a keepalive mechanism doesn't appeal to me at all. paul From owner-ipsec@lists.tislabs.com Fri Dec 3 15:22:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10770; Fri, 3 Dec 1999 15:22:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17506 Fri, 3 Dec 1999 16:32:30 -0500 (EST) Message-ID: <384837AE.BD8444E@redcreek.com> Date: Fri, 03 Dec 1999 13:35:42 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > On Fri, 3 Dec 1999, Slava Kavsan wrote: > > "Scott G. Kelly" wrote: > > > > > Maybe dead peer detection should not rely upon the presence of an IKE > > > SA. > > > > I like this approach, but it needs to be further analysed: > > > > - are there any attacks possible when using unprotected NOTIFYes for > > keep-alive? E.g. is "false-alive" attack is really an attack? > > It certainly is an attack. Whether you believe it is not serious enough to > protect against is another question, but it certainly is an attack. > > > - what if protected keep-alives are used when possible (IKE SA is around) > > and non-protected when there is no IKE SA? > > Then what's the point? If you go with unprotected keepalives later, why even > bother going with protected keepalives to begin with? In which case we go > back to your first point. > > > - use of keep-alives in this fashion will prevent us from taking advantage > > of using Ack-ed NOTIFY for keep-alives, because Ack-ed NOTIFY is always > > protected (unless this requirement can be relaxed for keep-alives) > > > - could resource-minded implementations when they need more memory "shrink" > > their SAs (instead of deleting them) to a bare minimum to only support > > keep-alive protection? > > > - could we use (somehow) IPSec-based keep-alives > > You could, but it would introduce a 'special' ipsec packet, which I do not > particularly care for. IPSEC shouldn't have to look at each packet and decide > if this is a 'control packet' or if this is a regular packet. > It would not *have to* be a special packet. It could be done through a standard policy based selector. An SA pair per peer is all that is required. So we have the ideas that a dead-peer detection could run in IKE, in IPsec as a special packet, in IPsec as a policy, or in the clear. Maybe there are more possibilities. What are the pros and cons of each? > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Fri Dec 3 15:26:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10822; Fri, 3 Dec 1999 15:26:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17568 Fri, 3 Dec 1999 16:46:14 -0500 (EST) Date: Fri, 3 Dec 1999 23:49:45 +0200 (EET) Message-Id: <199912032149.XAA14501@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912032138.QAA22709@tonga.xedia.com> References: <3847E9E5.4D7EB7A0@ire-ma.com> <199912031932.VAA00262@torni.ssh.fi> <199912032105.QAA22208@tonga.xedia.com> <199912032129.XAA23132@torni.ssh.fi> <199912032138.QAA22709@tonga.xedia.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > Tero> If I enable that kind of keep-alive, then it must be allowed, > Tero> i.e. I must make sure that the policy allows me to send packets > Tero> to gw if I want to use ping based keep-alive mechanism. > Yes, that would be the consequence. But that's not a good thing at > all. There are clear security benefits to having a tunnel whose users > have no ability to talk to the security gateway itself. Such as? Of course you can define the policy to only allow ICMP echo packets, nothing else. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Dec 3 15:37:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10951; Fri, 3 Dec 1999 15:36:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17694 Fri, 3 Dec 1999 17:10:30 -0500 (EST) Message-ID: <38484008.648B3A90@ire-ma.com> Date: Fri, 03 Dec 1999 17:11:20 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, I think that the most useful kind of hearbeat is the one that allows to detect if the peer machine is alive, and not individual SAs (phase 1 or 2). Detection of the dead peer will alow me to tear down all SAs to or through that peer. Andrew Krywaniuk wrote: > How about, to get this discussion going, I suggest a format and you (the > list) tell me if it seems appropriate. I can put this in a draft if there is > interest in standardization. > > I think that different types of heartbeats (phase 1/phase 2, > SA-referenced/host-referenced) provide different services, and we need to > support all kinds. > > I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then > search & replace with your favorite term. When I do refer to keep-alives at > the end of the document, I use Tim's definition (a mechanism for disabling > the peer's inactivity timeout). > > ---------------------------------------------------------------------------- > > As I see it, there are two types of heartbeats: phase 1 heartbeats and phase > 2 heartbeats. > > PHASE 1 HEARTBEATS: > > Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they > also tell you that the peer is still there. However, this is a sufficient > but not necessary condition. The peer may be a dangling implementation, in > which case they may not send phase 1 heartbeats even though they are still > running. > > However, phase 1 heartbeats still have a use because they ensure that the > peers will always agree on whether a phase 1 exists. It avoids the > clumsiness of one peer trying to send a message on the phase 1, receiving > NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase > 1 is down and needs to be rekeyed. > > Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as > a means of determining when an SA has gone down is vulnerable to DoS > attacks, whereas heartbeats are not. > > I'm not going to discuss a format for phase 1 heartbeats in this post > because IMHO it's not a technically difficult issue. Any one of a million > packet formats would suffice (info mode, config mode, acknowledged info > mode, some new exchange) and the only real issue is getting a group of > people to settle on any particular one. > > PHASE 2 HEARTBEATS: > > There are two types of phase 2 heartbeats: host-referenced and > SA-referenced. A host-referenced heartbeat is a protocol that runs across a > dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a > protocol that runs across an existing (user) SA. > > Host-referenced heartbeats can only be used to detect if the peer is still > up and running. Therefore, they are of limited use. (However, the fact that > they don't carry any sensitive information means that they they would never > need to be deleted before their natural lifetime. Therefore, they would be > the most reliable means of detecting if the peer is still alive since there > is no possibility of a phase 2 delete being lost.) > > SA-referenced heartbeats detect if a specific phase 2 SA is still working. > They also probably tell you when the peer is not there, since you wouldn't > expect a phase 2 SA to disappear without receiving a delete (although I've > been hearing some discussion of this recently on the list). However, they > are probably the most useful type of heartbeat, which is why I am going to > discuss them here. > > SA-referenced Phase 2 heartbeats are more technically complicated than other > heartbeats because: > > 1) They must not interfere with the peer's inactivity timeouts. > 2) They must not disturb any accounting services that may be running. > 3) They must not result in any packets ending up on the peer's red network. > 4) They must not assume that a phase 1 SA exists between the two peers. > > It is not, in general, possible to satisfy all of these constraints without > some degree of cooperation. Therefore, both peers must be aware of the > heartbeat scheme that is being used (i.e. it must be negotiated). > > In light of these constraints, I propose the following format: > > Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 > and peer 2 replies. In order to distinguish these pings from user traffic, > the source and destinations addresses are set to the hosts' black IPs. If > either side fails to receive a heartbeat within N*X seconds then they can > assume that the SA has gone down (and they should send a delete for it). (If > they fail to receive a ping but they receive other traffic on the SA then > something has gone wrong and they should log the event). Replay protection > is not required, as IPSec automatically provides it. > > It is not necessary for peer 2 to ever initiate the pings. However, to > increase reliability, if peer 2 does not receive a ping during the normal > window [X, X*3/2], he may force the issue by initiating a ping in the > opposite direction. > > This technique has the following advantages: > > 1) It satisfies all of the above constraints. > 2) It does not require the host to have any knowledge of the peer's red IP > or red subnet. > 3) Ping has universal brand-name recognition as a heartbeat protocol. > Therefore, no special payload format is required. > > and the following disadvantages: > > 1) The SPD must make a specific exception for ping packets between the black > IPs. > 2) The accounting service should know not to bill the user for this traffic. > > However, I believe these disadvantages will be inherent in any SA-referenced > heartbeat scheme. > > Note that a Host-referenced heartbeat scheme could be constructed in the > same way as an SA-referenced scheme, simply by negotiating a dedicated SA > using the black IPs as the endpoints. This could be done in tunnel mode > (presumably using the same policy exception that is used for SA-referenced > heartbeats) or it could simply be done in transport mode. > > FUTURE CONSIDERATIONS: > > One potential limitation of this scheme is that it does not generalize well > to keep-alives. The use of ping as a packet format is simple, but it doesn't > allow us to specify any additional information (all it says is > STILL_CONNECTED). It may be desirable to send extra information in the > packet. For example, a simple keep-alive (in the literal sense) scheme would > be to take the heartbeat scheme and add one extra bit of information (E.g. > STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer > that idle timeouts be disabled via. a negotiated attribute of the SA (if > feature negotiation ever gets standardized). > > There is no particular reason to use ping as transport, except for the fact > that it is already a universally accepted packet format and requires no > approval from IANA. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Fri Dec 3 15:43:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11036; Fri, 3 Dec 1999 15:43:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17647 Fri, 3 Dec 1999 16:59:25 -0500 (EST) Date: Sat, 4 Dec 1999 00:02:53 +0200 (EET) Message-Id: <199912032202.AAA08047@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Andrew Krywaniuk Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > How about, to get this discussion going, I suggest a format and you (the > list) tell me if it seems appropriate. I can put this in a draft if there is > interest in standardization. Good. I think the formats you suggested and text was ok, and I think you should make a draft about that. I think it might be good idea to write two drafts, one for the phase 1 SA heartbeats (if it is even needed?) and another for the phase 2 SA heartbeats. I think the the draft should include both host-referenced (usually VPNs or host-to-host IPsec connections), and SA-referenced (dialup, or remote users). I think it is easy to make the host-referenced as an subset of the SA-referenced, thus it is just some special case of the SA-referenced (what it does, it normally disables the per SA heartbeats, unless explicitly requested). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Fri Dec 3 16:49:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11930; Fri, 3 Dec 1999 16:49:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17959 Fri, 3 Dec 1999 18:29:28 -0500 (EST) Message-ID: <38485314.C744D453@redcreek.com> Date: Fri, 03 Dec 1999 15:32:36 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Slava Kavsan CC: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> <38484008.648B3A90@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan wrote: > > Andrew, > > I think that the most useful kind of hearbeat is the one that allows to detect > if the peer machine is alive, and not individual SAs (phase 1 or 2). Detection > of the dead peer will alow me to tear down all SAs to or through that peer. > Howdy () I concure. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Fri Dec 3 16:55:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12006; Fri, 3 Dec 1999 16:55:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18015 Fri, 3 Dec 1999 18:36:57 -0500 (EST) Message-ID: <384854D9.2E718D31@redcreek.com> Date: Fri, 03 Dec 1999 15:40:09 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () I just want to point out a 'pro' of using ping in the clear to do keepalive: You can include the record route option and save the last good path for reference when the peer becomes unreachable. I am not advocating this becaue I don't pretend to know the security consequences of running a dead-peer detection in the clear. Just food for thought. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Fri Dec 3 16:56:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12031; Fri, 3 Dec 1999 16:56:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18028 Fri, 3 Dec 1999 18:42:53 -0500 (EST) Message-ID: <38485565.BD1B210D@ire-ma.com> Date: Fri, 03 Dec 1999 18:42:29 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "CHINNA N.R. PELLACURU" CC: Jan Vilhuber , Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: matching GW addr to ID payload (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, Say I have an imaginary implementation that has two tables: 1) Pre-shared Keys table searched by source-ip-address 2) Phase 2 Policy Table searched by ID (which could be of all types: FQDN, USER_FQDN, IP Address, etc) What problem do you see in using Table #1 to select pre-shared keys and using Table #2 to select Phase 2 Policy based on ID Payload? From owner-ipsec@lists.tislabs.com Fri Dec 3 18:13:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14006; Fri, 3 Dec 1999 18:13:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18178 Fri, 3 Dec 1999 19:58:10 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 17:01:04 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: Slava Kavsan , "Scott G. Kelly" , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912031932.VAA00262@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Tero Kivinen wrote: > Jan Vilhuber writes: > > > - could we use (somehow) IPSec-based keep-alives > > You could, but it would introduce a 'special' ipsec packet, which I do not > > particularly care for. IPSEC shouldn't have to look at each packet and decide > > if this is a 'control packet' or if this is a regular packet. > > We already have that "special" packet. It is called ICMP echo > (ping)... I don't think there is need to create another one. If we use > IPsec based keep-alives, I think it should use normal ICMP echo (ping) > packets. You can't do that, since that would run up the packet/byte counts, which some people want to do accounting on and charge the customer for. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 18:20:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14244; Fri, 3 Dec 1999 18:20:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18234 Fri, 3 Dec 1999 20:09:58 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 17:12:59 -0800 (PST) From: Jan Vilhuber To: Bronislav Kavsan cc: "CHINNA N.R. PELLACURU" , Tero Kivinen , Mike Carney , Srinivasa Rao Addepalli , Tylor Allison , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <38485565.BD1B210D@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Bronislav Kavsan wrote: > Chinna, > > Say I have an imaginary implementation that has two tables: > > 1) Pre-shared Keys table searched by source-ip-address > 2) Phase 2 Policy Table searched by ID (which could be of all types: FQDN, USER_FQDN, IP > Address, etc) > > What problem do you see in using Table #1 to select pre-shared keys and > using Table #2 to select Phase 2 Policy based on ID Payload? > Unless you link the two tables, you can't do this (for what SHOULD be obvious reasons). For example, you'd have to require that ID_USER_FQDN=vilhuber@cisco.com can only log in using source-ip-address 1.1.1.1 and nothing else. Or ID_IPV4=1.1.1.1 can only log in using source-ip-address 1.1.1.1. Otherwise, if you don't make that link, you can't use the ID to select policy, since you haven't verified the policy. And if you DO link the two tables, you don't work anymore through NAT (group keys or not), which is the current problem. So you have two options: Do it as you already do, and link the tables, in which case you CAN pick policy (but then you'll have to also link ID_FQN and ID_USER_FQDN for the source-ip-address; something I know you currently don't do), or you ignore the ID payload altogether, and simply pick policy on what was used to pick the key, i.e. the source-ip-address. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 18:47:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14480; Fri, 3 Dec 1999 18:47:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18347 Fri, 3 Dec 1999 20:44:56 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 17:48:01 -0800 (PST) From: Jan Vilhuber To: Slava Kavsan cc: "CHINNA N.R. PELLACURU" , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <38480C53.D3D8FC42@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Slava Kavsan wrote: > "CHINNA N.R. PELLACURU" wrote: > > > Is this acceptable, or should we enforce that ID and the IP address used > > should be equal? > > I would say yes in the case when ID Payload contains IP Address type. > But we should also allow to have ID Payload to contain FQDN type (and other > non-IP IDs) and is use it to select the Policy entry. > So if you can't check the FQDN ID type, why would you bother checking the IDV4 ID type? What do you gain by this? jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 18:47:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14496; Fri, 3 Dec 1999 18:47:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18374 Fri, 3 Dec 1999 20:47:21 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 17:50:26 -0800 (PST) From: Jan Vilhuber To: Slava Kavsan cc: "CHINNA N.R. PELLACURU" , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <384826CC.73979B0C@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Slava Kavsan wrote: > Well... in this case neither my scheme nor Jan's scheme are going to work with > NAT. Says who? My scheme works through NAT, at least static NAT: Ignore the ID payload, and store your keys based on the NAT'd address. Works just fine. For dynamic NAT as well as dynamic IP addresses, you'll need (shudder) group keys (or better yet: Certs). jan > Unless users are willing to switch to alternatives like Aggressive Mode or > Certificate-based authentication, NAT users will be out of luck :(( > . > > "CHINNA N.R. PELLACURU" wrote: > > > On Fri, 3 Dec 1999, Slava Kavsan wrote: > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > Is this acceptable, or should we enforce that ID and the IP address used > > > > should be equal? > > > > > > I would say yes in the case when ID Payload contains IP Address type. > > > But we should also allow to have ID Payload to contain FQDN type (and other > > > non-IP IDs) and is use it to select the Policy entry. > > > > > > > > > > > > > If you do not check that the ID used to search the pre-shared key is the > > same as the ID payload content, then you should not use the ID payload > > content to select policy. IE, in MM using pre-shared keys, only the source > > IP address on the negotiation can be used to select policy. > > > > If I know the pre-shared key associated with IP1, then the gateway should > > select the policy associated with IP1, and should not select the policy > > based on what I sent in the ID payload (if this is different from IP1). > > > > -chinna > > > > chinna narasimha reddy pellacuru > > s/w engineer > > -- > Bronislav Kavsan > IRE Secure Solutions, Inc. > 100 Conifer Hill Drive Suite 513 > Danvers, MA 01923 > voice: 978-539-4816 > http://www.ire.com > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 18:59:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14610; Fri, 3 Dec 1999 18:59:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18416 Fri, 3 Dec 1999 20:56:32 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 17:59:37 -0800 (PST) From: Jan Vilhuber To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not really in favor pf phase 2 heartbeats, mainly coz I can't see a good way of implementing them (sending a packet through the IPSEC tunnel and NOT incrementing the packet counts seems like a bad idea; do you keep separate accounting counts vs. lifetime counts? Let's keep it simple). What about this: when sending a phase1-heartbeat (where we still need to agree what this would look like) from host A to host B, why not include in it all SPI's that host A shares with host B. If host B has a few SPI's that host A didn't include in the heartbeat, then they are obviously deleted, and host B should delete it's SPIS for those. If you do this in an ack'd scenario, host A would send a list to B, and B would send back a subset of that list that it shares with A, which would let both of them delete ones the other doesn't know about, and come up with a common subset. That would alleviate the need for phase2-heartbeats. jan On Fri, 3 Dec 1999, Andrew Krywaniuk wrote: > How about, to get this discussion going, I suggest a format and you (the > list) tell me if it seems appropriate. I can put this in a draft if there is > interest in standardization. > > I think that different types of heartbeats (phase 1/phase 2, > SA-referenced/host-referenced) provide different services, and we need to > support all kinds. > > I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then > search & replace with your favorite term. When I do refer to keep-alives at > the end of the document, I use Tim's definition (a mechanism for disabling > the peer's inactivity timeout). > > ---------------------------------------------------------------------------- > > As I see it, there are two types of heartbeats: phase 1 heartbeats and phase > 2 heartbeats. > > > PHASE 1 HEARTBEATS: > > Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they > also tell you that the peer is still there. However, this is a sufficient > but not necessary condition. The peer may be a dangling implementation, in > which case they may not send phase 1 heartbeats even though they are still > running. > > However, phase 1 heartbeats still have a use because they ensure that the > peers will always agree on whether a phase 1 exists. It avoids the > clumsiness of one peer trying to send a message on the phase 1, receiving > NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase > 1 is down and needs to be rekeyed. > > Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as > a means of determining when an SA has gone down is vulnerable to DoS > attacks, whereas heartbeats are not. > > I'm not going to discuss a format for phase 1 heartbeats in this post > because IMHO it's not a technically difficult issue. Any one of a million > packet formats would suffice (info mode, config mode, acknowledged info > mode, some new exchange) and the only real issue is getting a group of > people to settle on any particular one. > > > PHASE 2 HEARTBEATS: > > There are two types of phase 2 heartbeats: host-referenced and > SA-referenced. A host-referenced heartbeat is a protocol that runs across a > dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a > protocol that runs across an existing (user) SA. > > Host-referenced heartbeats can only be used to detect if the peer is still > up and running. Therefore, they are of limited use. (However, the fact that > they don't carry any sensitive information means that they they would never > need to be deleted before their natural lifetime. Therefore, they would be > the most reliable means of detecting if the peer is still alive since there > is no possibility of a phase 2 delete being lost.) > > SA-referenced heartbeats detect if a specific phase 2 SA is still working. > They also probably tell you when the peer is not there, since you wouldn't > expect a phase 2 SA to disappear without receiving a delete (although I've > been hearing some discussion of this recently on the list). However, they > are probably the most useful type of heartbeat, which is why I am going to > discuss them here. > > SA-referenced Phase 2 heartbeats are more technically complicated than other > heartbeats because: > > 1) They must not interfere with the peer's inactivity timeouts. > 2) They must not disturb any accounting services that may be running. > 3) They must not result in any packets ending up on the peer's red network. > 4) They must not assume that a phase 1 SA exists between the two peers. > > It is not, in general, possible to satisfy all of these constraints without > some degree of cooperation. Therefore, both peers must be aware of the > heartbeat scheme that is being used (i.e. it must be negotiated). > > In light of these constraints, I propose the following format: > > Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 > and peer 2 replies. In order to distinguish these pings from user traffic, > the source and destinations addresses are set to the hosts' black IPs. If > either side fails to receive a heartbeat within N*X seconds then they can > assume that the SA has gone down (and they should send a delete for it). (If > they fail to receive a ping but they receive other traffic on the SA then > something has gone wrong and they should log the event). Replay protection > is not required, as IPSec automatically provides it. > > It is not necessary for peer 2 to ever initiate the pings. However, to > increase reliability, if peer 2 does not receive a ping during the normal > window [X, X*3/2], he may force the issue by initiating a ping in the > opposite direction. > > This technique has the following advantages: > > 1) It satisfies all of the above constraints. > 2) It does not require the host to have any knowledge of the peer's red IP > or red subnet. > 3) Ping has universal brand-name recognition as a heartbeat protocol. > Therefore, no special payload format is required. > > and the following disadvantages: > > 1) The SPD must make a specific exception for ping packets between the black > IPs. > 2) The accounting service should know not to bill the user for this traffic. > > However, I believe these disadvantages will be inherent in any SA-referenced > heartbeat scheme. > > Note that a Host-referenced heartbeat scheme could be constructed in the > same way as an SA-referenced scheme, simply by negotiating a dedicated SA > using the black IPs as the endpoints. This could be done in tunnel mode > (presumably using the same policy exception that is used for SA-referenced > heartbeats) or it could simply be done in transport mode. > > > FUTURE CONSIDERATIONS: > > One potential limitation of this scheme is that it does not generalize well > to keep-alives. The use of ping as a packet format is simple, but it doesn't > allow us to specify any additional information (all it says is > STILL_CONNECTED). It may be desirable to send extra information in the > packet. For example, a simple keep-alive (in the literal sense) scheme would > be to take the heartbeat scheme and add one extra bit of information (E.g. > STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer > that idle timeouts be disabled via. a negotiated attribute of the SA (if > feature negotiation ever gets standardized). > > There is no particular reason to use ping as transport, except for the fact > that it is already a universally accepted packet format and requires no > approval from IANA. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 19:04:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA14698; Fri, 3 Dec 1999 19:04:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18452 Fri, 3 Dec 1999 21:01:15 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 3 Dec 1999 18:04:17 -0800 (PST) From: Jan Vilhuber To: Tylor Allison cc: Stephen Kent , Bronislav Kavsan , ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Tylor Allison wrote: > On Fri, 3 Dec 1999, Stephen Kent wrote: > > > I hate to jump in late to this discussion, as I may have lost the > > context. There is a big difference between asserting an address as an > > identity in the IP header, vs. asserting it in an IKE exchange, IF > > one uses certificates to authenticate the asserted identity in IKE. > > One can imagine several PKI scenarios that would enable one to have > > reasonable confidence in a cert issued for an address. > > > > Steve > > This seems to be getting back to my original questions which started all > this. The basis of these questions was what decisions (if any) can be > made based on the source address from the IP header. For pre-shared > password authentication in Main Mode, it's evident that this source IP > address drives the authentication by determining which key to select. I > would argue that the actual ID payload should still drive any policy > decisions. Why? How can you trust it? Say that *you* are allowed to access top-secret documents. I, being of lower rank, am not allowed to see anything CLOSE to top-secret. Now I stick in the ID payload with YOUR name, and voila! I can now read all top-secret documents. How do you prevent this?! If you want to select policy via ID you MUST link it to whatever selected the key. Either you have a table linking ID_FQDN or ID_USER_FQDN to the source-ip-address (hopefully the NAT'd one, if you're coming through NAT), or you have a table linking ID_IPV4 to the source-ip-address (again, hopefully the NAT'd one, which could lead to a table like: ID_IPV4=1.1.1.1 == source-ip-address 199.100.111.222, which seems pretty silly to me). jan > Whether or not the ID payload needs to be an IPV4_ADDR which > matches the source address is still unclear to me. > > What interests me more, however: can any decisions be made based on the > packet's source IP address for cert-based policies? For instance, for > signature authentication in main mode where certificates are not available > online, when responding to a remote request, one needs to either assume > that the remote cert is not locally available (and a certificate request > must always be made), or one can use the source IP address to look up > policy info for the remote host and determine if the remote cert is locally > available (and if not, then send a certificate request). This must be done > in the exchange prior to receiving the remote side's identity payload... > since the identity payload is received in the last round of the exchange, > and a certificate request cannot be made it this time, since it would > extend the exchange. > > Along these same lines, if you set up a static VPN policy and you know what > the remote IP address is, when you receive the first payload of a main mode > exchange from that remote IP address, can you immediately fail the exchange > if attributes in the SA payload do not match the attributes that you have > set in your policy? > > Also, going back to Steve's message (and one of my original questions)... > Given a certificate which is assigned a specific IP address (e.g. in > subjectAltName extension), I think it's clear that if I use a IPV4_ADDR as > the identity payload for the exchange, that it needs to match the one > presented in the cert. Is anyone checking to see if this matches the source > IP address from the packet? Or if I use a DN of the cert as the identity, > but the cert contains the IP address, does anyone check the cert's asserted > IP address with the packet? > > All of this then goes back to, what breaks if there can be multiple IP > addresses associated with the remote host (e.g. aliased addresses for > the interface, or multiple interfaces). This clearly breaks the pre-shared > key case (unless you set the same key for each of the aliased addresses). > If vendors are using the source IP address for other purposes (initial > policy checks, cert lookup, etc.), this may break other authentication > methods as well. I know this isn't a very likely occurance, but it is > still a concert for us. I'm just wondering if other vendors out there have > addressed this issue, and can provide any insight on how they plan to > handle it. > > Thanks! > > Tylor > > --- > Tylor Allison tylor_allison@securecomputing.com > Secure Computing Corporation > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri Dec 3 23:14:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA16958; Fri, 3 Dec 1999 23:14:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18895 Sat, 4 Dec 1999 00:37:03 -0500 (EST) From: Mike Carney Message-Id: <199912040539.XAA07405@jumpsrv.stp.securecomputing.com> Subject: Re: matching GW addr to ID payload (fwd) To: vilhuber@cisco.com (Jan Vilhuber) Date: Fri, 3 Dec 1999 23:39:57 -0600 (CST) Cc: allison@securecomputing.com, kent@bbn.com, bkavsan@ire-ma.com, ipsec@lists.tislabs.com In-Reply-To: from "Jan Vilhuber" at Dec 3, 99 06:04:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > On Fri, 3 Dec 1999, Tylor Allison wrote: > > > > > > This seems to be getting back to my original questions which started all > > this. The basis of these questions was what decisions (if any) can be > > made based on the source address from the IP header. For pre-shared > > password authentication in Main Mode, it's evident that this source IP > > address drives the authentication by determining which key to select. I > > would argue that the actual ID payload should still drive any policy > > decisions. > > Why? How can you trust it? You can trust it because there is a private key associated with the cert that contains a match to the identity payload. You will be using the public key contained within that certificate in order to proceed with Main Mode. Regards, Michael Carney > > Say that *you* are allowed to access top-secret documents. I, being of lower > rank, am not allowed to see anything CLOSE to top-secret. > > Now I stick in the ID payload with YOUR name, and voila! I can now read all > top-secret documents. How do you prevent this?! You don't have "My" private key > > If you want to select policy via ID you MUST link it to whatever selected the > key. Either you have a table linking ID_FQDN or ID_USER_FQDN to the > source-ip-address (hopefully the NAT'd one, if you're coming through NAT), or > you have a table linking ID_IPV4 to the source-ip-address (again, hopefully > the NAT'd one, which could lead to a table like: ID_IPV4=1.1.1.1 == > source-ip-address 199.100.111.222, which seems pretty silly to me). > > jan > > > > Whether or not the ID payload needs to be an IPV4_ADDR which > > matches the source address is still unclear to me. > > > > What interests me more, however: can any decisions be made based on the > > packet's source IP address for cert-based policies? For instance, for > > signature authentication in main mode where certificates are not available > > online, when responding to a remote request, one needs to either assume > > that the remote cert is not locally available (and a certificate request > > must always be made), or one can use the source IP address to look up > > policy info for the remote host and determine if the remote cert is locally > > available (and if not, then send a certificate request). This must be done > > in the exchange prior to receiving the remote side's identity payload... > > since the identity payload is received in the last round of the exchange, > > and a certificate request cannot be made it this time, since it would > > extend the exchange. > > > > Along these same lines, if you set up a static VPN policy and you know what > > the remote IP address is, when you receive the first payload of a main mode > > exchange from that remote IP address, can you immediately fail the exchange > > if attributes in the SA payload do not match the attributes that you have > > set in your policy? > > > > Also, going back to Steve's message (and one of my original questions)... > > Given a certificate which is assigned a specific IP address (e.g. in > > subjectAltName extension), I think it's clear that if I use a IPV4_ADDR as > > the identity payload for the exchange, that it needs to match the one > > presented in the cert. Is anyone checking to see if this matches the source > > IP address from the packet? Or if I use a DN of the cert as the identity, > > but the cert contains the IP address, does anyone check the cert's asserted > > IP address with the packet? > > > > All of this then goes back to, what breaks if there can be multiple IP > > addresses associated with the remote host (e.g. aliased addresses for > > the interface, or multiple interfaces). This clearly breaks the pre-shared > > key case (unless you set the same key for each of the aliased addresses). > > If vendors are using the source IP address for other purposes (initial > > policy checks, cert lookup, etc.), this may break other authentication > > methods as well. I know this isn't a very likely occurance, but it is > > still a concert for us. I'm just wondering if other vendors out there have > > addressed this issue, and can provide any insight on how they plan to > > handle it. > > > > Thanks! > > > > Tylor > > > > --- > > Tylor Allison tylor_allison@securecomputing.com > > Secure Computing Corporation > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Sat Dec 4 10:44:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25388; Sat, 4 Dec 1999 10:44:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19863 Sat, 4 Dec 1999 12:18:25 -0500 (EST) From: Mike Carney Message-Id: <199912041721.LAA07878@jumpsrv.stp.securecomputing.com> Subject: Re: matching GW addr to ID payload (fwd) To: ipsec@lists.tislabs.com Date: Sat, 4 Dec 1999 11:21:25 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, Oops, your right, my mistake, (Tylor and I had talked earlier so I didn't read what he wrote carefully enough) I agree that the authentication information is tied to the source IP of the packet, thus the policy must be tied to the source IP of the packet. Another question of Tylors that I would like to repeat is as follows: If the authentication method is CERT based and the ID payload is IPV4_ADDR what restrictions must we place on the source IP of the packet and why? Second question: If your phase 1 policy (crypto/hash/oakley group) is tied to your phase 1 identity. How do you handle the problem that your phase 1 parameters are negotiated prior to knowing the phase 1 identity (In MM). Our current approach has two aspects. The first is whenever possible select the phase 1 parameters based on the source IP of the ISAKMP packet. This is where we run into problems with aliased address and multiple routes from the peer selecting different interfaces out of the peer. The second is when the remote peer address is not known in advance. In this case we select the highest security level possible and verify that the negotiated Phase 1 parameters meet the minimum requirements of the policy. If they don't we abort the negotiation. Another approach might be to let the negotiation proceed to the point of Phase 1 Identities being exchanged, then if the negotiated Phase 1 does not meet the exact requriements, abort the negotiation and turn the responder into the initiator (for phase 1), and initiate. However, this could get one into an a never ending cycle if the two sides have conflicting Phase 1 requirements. Agressive mode does have it's advantages :) Regards, Michael Carney > > Mike Carney wrote: > > > > > > > > > > On Fri, 3 Dec 1999, Tylor Allison wrote: > > > > > > > > > > > > > > > > > > This seems to be getting back to my original questions which started all > > > > > this. The basis of these questions was what decisions (if any) can be > > > > > made based on the source address from the IP header. For pre-shared > > > > > password authentication in Main Mode, it's evident that this source IP > > > > > address drives the authentication by determining which key to select. I > > > > > would argue that the actual ID payload should still drive any policy > > > > > decisions. > > > > > > > > Why? How can you trust it? > > > > > > You can trust it because there is a private key associated with the > > > cert that contains a match to the identity payload. > > > You will be using the public key contained within that certificate in > > > order to proceed with Main Mode. > > > > > > Regards, > > > Michael Carney > > > > > > > > > > > Say that *you* are allowed to access top-secret documents. I, being of lower > > > > rank, am not allowed to see anything CLOSE to top-secret. > > > > > > > > Now I stick in the ID payload with YOUR name, and voila! I can now read all > > > > top-secret documents. How do you prevent this?! > > > > > > You don't have "My" private key > > > > > > > > > > > If you want to select policy via ID you MUST link it to whatever selected the > > > > key. Either you have a table linking ID_FQDN or ID_USER_FQDN to the > > > > source-ip-address (hopefully the NAT'd one, if you're coming through NAT), or > > > > you have a table linking ID_IPV4 to the source-ip-address (again, hopefully > > > > the NAT'd one, which could lead to a table like: ID_IPV4=1.1.1.1 == > > > > source-ip-address 199.100.111.222, which seems pretty silly to me). > > > > > > > > jan > > > > > > > > > > > > > Whether or not the ID payload needs to be an IPV4_ADDR which > > > > > matches the source address is still unclear to me. > > > > > > > > > > What interests me more, however: can any decisions be made based on the > > > > > packet's source IP address for cert-based policies? For instance, for > > > > > signature authentication in main mode where certificates are not available > > > > > online, when responding to a remote request, one needs to either assume > > > > > that the remote cert is not locally available (and a certificate request > > > > > must always be made), or one can use the source IP address to look up > > > > > policy info for the remote host and determine if the remote cert is locally > > > > > available (and if not, then send a certificate request). This must be done > > > > > in the exchange prior to receiving the remote side's identity payload... > > > > > since the identity payload is received in the last round of the exchange, > > > > > and a certificate request cannot be made it this time, since it would > > > > > extend the exchange. > > > > > > > > > > Along these same lines, if you set up a static VPN policy and you know what > > > > > the remote IP address is, when you receive the first payload of a main mode > > > > > exchange from that remote IP address, can you immediately fail the exchange > > > > > if attributes in the SA payload do not match the attributes that you have > > > > > set in your policy? > > > > > > > > > > Also, going back to Steve's message (and one of my original questions)... > > > > > Given a certificate which is assigned a specific IP address (e.g. in > > > > > subjectAltName extension), I think it's clear that if I use a IPV4_ADDR as > > > > > the identity payload for the exchange, that it needs to match the one > > > > > presented in the cert. Is anyone checking to see if this matches the source > > > > > IP address from the packet? Or if I use a DN of the cert as the identity, > > > > > but the cert contains the IP address, does anyone check the cert's asserted > > > > > IP address with the packet? > > > > > > > > > > All of this then goes back to, what breaks if there can be multiple IP > > > > > addresses associated with the remote host (e.g. aliased addresses for > > > > > the interface, or multiple interfaces). This clearly breaks the pre-shared > > > > > key case (unless you set the same key for each of the aliased addresses). > > > > > If vendors are using the source IP address for other purposes (initial > > > > > policy checks, cert lookup, etc.), this may break other authentication > > > > > methods as well. I know this isn't a very likely occurance, but it is > > > > > still a concert for us. I'm just wondering if other vendors out there have > > > > > addressed this issue, and can provide any insight on how they plan to > > > > > handle it. > > > > > > > > > > Thanks! > > > > > > > > > > Tylor > > > > > > > > > > --- > > > > > Tylor Allison tylor_allison@securecomputing.com > > > > > Secure Computing Corporation > > > > > > > > > > > > > > > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Sat Dec 4 11:56:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25801; Sat, 4 Dec 1999 11:56:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20092 Sat, 4 Dec 1999 13:47:56 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Sat, 4 Dec 1999 10:51:01 -0800 (PST) From: Jan Vilhuber To: Mike Carney cc: allison@securecomputing.com, kent@bbn.com, bkavsan@ire-ma.com, ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) In-Reply-To: <199912040539.XAA07405@jumpsrv.stp.securecomputing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Dec 1999, Mike Carney wrote: > > > > On Fri, 3 Dec 1999, Tylor Allison wrote: > > > > > > > > > > This seems to be getting back to my original questions which started all > > > this. The basis of these questions was what decisions (if any) can be > > > made based on the source address from the IP header. For pre-shared > > > password authentication in Main Mode, it's evident that this source IP > > > address drives the authentication by determining which key to select. I > > > would argue that the actual ID payload should still drive any policy > > > decisions. > > > > Why? How can you trust it? > > You can trust it because there is a private key associated with the > cert that contains a match to the identity payload. > You will be using the public key contained within that certificate in > order to proceed with Main Mode. > But we're talking about pre-shared keys, not certs. For certs you are correct (I think), but for pre-shared keys and main-mode you are wrong. jan > Regards, > Michael Carney > > > > > Say that *you* are allowed to access top-secret documents. I, being of lower > > rank, am not allowed to see anything CLOSE to top-secret. > > > > Now I stick in the ID payload with YOUR name, and voila! I can now read all > > top-secret documents. How do you prevent this?! > > You don't have "My" private key > > > > > If you want to select policy via ID you MUST link it to whatever selected the > > key. Either you have a table linking ID_FQDN or ID_USER_FQDN to the > > source-ip-address (hopefully the NAT'd one, if you're coming through NAT), or > > you have a table linking ID_IPV4 to the source-ip-address (again, hopefully > > the NAT'd one, which could lead to a table like: ID_IPV4=1.1.1.1 == > > source-ip-address 199.100.111.222, which seems pretty silly to me). > > > > jan > > > > > > > Whether or not the ID payload needs to be an IPV4_ADDR which > > > matches the source address is still unclear to me. > > > > > > What interests me more, however: can any decisions be made based on the > > > packet's source IP address for cert-based policies? For instance, for > > > signature authentication in main mode where certificates are not available > > > online, when responding to a remote request, one needs to either assume > > > that the remote cert is not locally available (and a certificate request > > > must always be made), or one can use the source IP address to look up > > > policy info for the remote host and determine if the remote cert is locally > > > available (and if not, then send a certificate request). This must be done > > > in the exchange prior to receiving the remote side's identity payload... > > > since the identity payload is received in the last round of the exchange, > > > and a certificate request cannot be made it this time, since it would > > > extend the exchange. > > > > > > Along these same lines, if you set up a static VPN policy and you know what > > > the remote IP address is, when you receive the first payload of a main mode > > > exchange from that remote IP address, can you immediately fail the exchange > > > if attributes in the SA payload do not match the attributes that you have > > > set in your policy? > > > > > > Also, going back to Steve's message (and one of my original questions)... > > > Given a certificate which is assigned a specific IP address (e.g. in > > > subjectAltName extension), I think it's clear that if I use a IPV4_ADDR as > > > the identity payload for the exchange, that it needs to match the one > > > presented in the cert. Is anyone checking to see if this matches the source > > > IP address from the packet? Or if I use a DN of the cert as the identity, > > > but the cert contains the IP address, does anyone check the cert's asserted > > > IP address with the packet? > > > > > > All of this then goes back to, what breaks if there can be multiple IP > > > addresses associated with the remote host (e.g. aliased addresses for > > > the interface, or multiple interfaces). This clearly breaks the pre-shared > > > key case (unless you set the same key for each of the aliased addresses). > > > If vendors are using the source IP address for other purposes (initial > > > policy checks, cert lookup, etc.), this may break other authentication > > > methods as well. I know this isn't a very likely occurance, but it is > > > still a concert for us. I'm just wondering if other vendors out there have > > > addressed this issue, and can provide any insight on how they plan to > > > handle it. > > > > > > Thanks! > > > > > > Tylor > > > > > > --- > > > Tylor Allison tylor_allison@securecomputing.com > > > Secure Computing Corporation > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sat Dec 4 20:19:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14192; Sat, 4 Dec 1999 20:19:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20938 Sat, 4 Dec 1999 21:36:33 -0500 (EST) Message-ID: <001301bf3ecb$d8bcd380$640673ca@cc.uestc.edu.cn> From: chenl@mail.sc.cninfo.net (Publishing User) To: "linux-ipsec" Cc: "ipsec@lists.tislabs." Subject: Can u suggest some reading references? Date: Sun, 5 Dec 1999 10:52:57 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01BF3F0E.E3BBF020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0010_01BF3F0E.E3BBF020 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkknbSBhIHN0dWRlbnQgb2YgY29tcHV0ZXIgc2NpZW5jZSwgZG9pbmcgc29tZSB3b3Jr IG9uIElQIHNlY3VyaXR5LiBGb3Igd3JpdGluZyBhIHRoZXNpcyBub3csIEkgaGF2ZSB0byByZWFk IHJlZmVyZW5jZXMgb24gdGhlIHNlY3VyaXR5IHByb2JsZW0gb2YgVENQL0lQIGFzIG11Y2ggYXMg cG9zc2libGUuIENhbiB1IHN1Z2dlc3Qgc29tZSByZWFkaW5nIHJlZmVyZW5jZXMgb2YgaXQ/DQoN ClRoYW5rcy4NCkNoZW4gTC4NCg== ------=_NextPart_000_0010_01BF3F0E.E3BBF020 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSw8L0ZPTlQ+PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTM+SSdtIGEgc3R1ZGVudCBvZiBj b21wdXRlciBzY2llbmNlLCBkb2luZyBzb21lIHdvcmsgb24gSVAgDQpzZWN1cml0eS4gRm9yIHdy aXRpbmcgYSB0aGVzaXMgbm93LCBJJm5ic3A7aGF2ZSB0byByZWFkIHJlZmVyZW5jZXMgb24gdGhl IA0Kc2VjdXJpdHkgcHJvYmxlbSBvZiBUQ1AvSVAgYXMgbXVjaCBhcyBwb3NzaWJsZS4gQ2FuIHUg c3VnZ2VzdCBzb21lIHJlYWRpbmcgDQpyZWZlcmVuY2VzIG9mIGl0PzwvRk9OVD48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcy48L0RJVj4NCjxESVY+Q2hlbiBMLjwvRElWPjwv Qk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0010_01BF3F0E.E3BBF020-- From owner-ipsec@lists.tislabs.com Sun Dec 5 08:07:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08024; Sun, 5 Dec 1999 08:07:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21956 Sun, 5 Dec 1999 09:38:26 -0500 (EST) Message-ID: <384A799A.783B6381@redcreek.com> Date: Sun, 05 Dec 1999 06:41:30 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Carney CC: ipsec@lists.tislabs.com Subject: Re: matching GW addr to ID payload (fwd) References: <199912041721.LAA07878@jumpsrv.stp.securecomputing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike, Mike Carney wrote: > Another question of Tylors that I would like to repeat is as follows: > > If the authentication method is CERT based and the ID payload is IPV4_ADDR > what restrictions must we place on the source IP of the packet and why? I think requiring that the ID payload contents match some field in the cert (e.g. subjectAltName) is necessary and sufficient. > Second question: > > If your phase 1 policy (crypto/hash/oakley group) is tied to your phase 1 > identity. How do you handle the problem that your phase 1 parameters are > negotiated prior to knowing the phase 1 identity (In MM). > > Our current approach has two aspects. > > The first is whenever possible select the phase 1 parameters based on the > source IP of the ISAKMP packet. This is where we run into problems with > aliased address and multiple routes from the peer selecting different > interfaces out of the peer. > > The second is when the remote peer address is not known in advance. In > this case we select the highest security level possible and > verify that the negotiated Phase 1 parameters meet the minimum requirements > of the policy. If they don't we abort the negotiation. > > Another approach might be to let the negotiation proceed to the point > of Phase 1 Identities being exchanged, then if the negotiated Phase 1 does > not meet the exact requriements, abort the negotiation and turn the responder > into the initiator (for phase 1), and initiate. However, this could get one > into an a never ending cycle if the two sides have conflicting Phase 1 > requirements. > This is a problem we all have, and it would be nice to come up with something better than our current options. We currently verify that suggested options are acceptable for *some* SA before responding with the first message. If possible (i.e. if we have only address-based policies for that peer), we verify that the parameters match some policy rule for that particular peer before proceeding. One recovery strategy if the negotiation fails is to send a notify message and use one of the new payloads described in the notify messages draft to give the peer a clue as to an acceptable policy. Obviously, this has some security implications in terms of exposing your policy, but I don't think there are any real issues here. Scott From owner-ipsec@lists.tislabs.com Sun Dec 5 10:09:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09036; Sun, 5 Dec 1999 10:09:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22115 Sun, 5 Dec 1999 11:34:14 -0500 (EST) Message-ID: <384A9711.C4C82DF9@public.uni-hamburg.de> Date: Sun, 05 Dec 1999 17:47:13 +0100 From: Thilo Rusche X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Incorporation of AES into IPSec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, are there any plans to make AES, once it has been standardized, a required algorithm for ESP? And if not, when will DES be replaced with something more secure as the mandatory encryption algorithm? Any pointers to appropriate readings would be appreciated. Thanks, Thilo Rusche From owner-ipsec@lists.tislabs.com Sun Dec 5 10:14:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09090; Sun, 5 Dec 1999 10:14:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22138 Sun, 5 Dec 1999 11:49:55 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Thilo Rusche Cc: ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Dec 1999 11:53:24 -0500 Message-Id: <19991205165329.87E9041F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <384A9711.C4C82DF9@public.uni-hamburg.de>, Thilo Rusche writes: > Hi, > > are there any plans to make AES, once it has been standardized, a > required algorithm for ESP? And if not, when will DES be replaced with > something more secure as the mandatory encryption algorithm? Any > pointers to appropriate readings would be appreciated. > This has been discussed extensively. AES isn't ready yet, and won't be announced till ~August. We can't standardize something that doesn't exist. It's an open question when it will be considered trustworthy enough. For now, make sure your code is AES-ready (larger key sizes and larger block sizes), and use 3DES. --Steve Bellovin From owner-ipsec@lists.tislabs.com Sun Dec 5 19:15:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25001; Sun, 5 Dec 1999 19:15:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23194 Sun, 5 Dec 1999 20:39:54 -0500 (EST) Date: Mon, 6 Dec 1999 03:43:25 +0200 (EET) Message-Id: <199912060143.DAA21299@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jan Vilhuber Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > What about this: when sending a phase1-heartbeat (where we still need to > agree what this would look like) from host A to host B, why not include in it > all SPI's that host A shares with host B. If host B has a few SPI's that host > A didn't include in the heartbeat, then they are obviously deleted, and host > B should delete it's SPIS for those. That could be one way to do it, but it only allows machine to have 16376 SAs up at one time (64 kB packet limit at the UDP level). I have been doing testing with bigger number of SAs between hosts already now, and I wonder what amount of SAs we have in 5-10 years.... Is that amount enough? -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Dec 5 19:15:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25025; Sun, 5 Dec 1999 19:15:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23134 Sun, 5 Dec 1999 20:32:38 -0500 (EST) Date: Mon, 6 Dec 1999 03:35:43 +0200 (EET) Message-Id: <199912060135.DAA27830@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jan Vilhuber Cc: Slava Kavsan , "Scott G. Kelly" , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: References: <199912031932.VAA00262@torni.ssh.fi> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > We already have that "special" packet. It is called ICMP echo > > (ping)... I don't think there is need to create another one. If we use > > IPsec based keep-alives, I think it should use normal ICMP echo (ping) > > packets. > > You can't do that, since that would run up the packet/byte counts, which some > people want to do accounting on and charge the customer for. How about counting the bytes/packets only if they are routed through the gateway, not if they are destinationed to the gateway. You have to do special code for the special packets for the accounting anyways, so you can also detect that this is normal ping packet destinationed to the gateway, and if so, do not add it to the counts. If you use ping packets, and you are not doing accounting you don't have to do anything special, everything works immediately. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 6 08:55:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17920; Mon, 6 Dec 1999 08:55:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24989 Mon, 6 Dec 1999 10:03:27 -0500 (EST) Message-ID: <384BD0FE.35DF2320@thawte.com> Date: Mon, 06 Dec 1999 17:06:38 +0200 From: Mark Shuttleworth Organization: Thawte Certification X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec References: <19991205165329.87E9041F16@SIGABA.research.att.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms34E73F09BA8674A73111ABB2" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms34E73F09BA8674A73111ABB2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all Will AES's primary advantage over 3DES be speed? I know that DES is now considered weak... but that's because if its keyspace of 56 bits. Is 3DES considered plenty strong but slow? If you were wanting to protect data for 50 years, would 3DES be good enough? -- Mark Shuttleworth Thawte --------------ms34E73F09BA8674A73111ABB2 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 MIIIRwYJKoZIhvcNAQcCoIIIODCCCDQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BjUwggL0MIICXaADAgECAgJarDANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MTIxODEyMzgyOFoXDTk5MTIxODEyMzgyOFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEA4IQUDeMHoSSClHPcZgNMePwYJhJRfS/P+7Wl66ZOxzdw0Dso +hDBFmTt0y1z7TKnbkV9dWnLcSK6pRqPOd7/tQIDAQABo4GTMIGQMBEGCWCGSAGG+EIBAQQE AwIFoDAOBgNVHQ8BAf8EBAMCBaAwPAYFK2UBBAEEMzAxAgEAMCwwCgIBAQQFbWFya3MwDAIB AgQHZGVtb2lkMTAQAgEDBAtnaG9zdGJ1c3RlcjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FP4+YJxrjA+w2DPGysYeWLBxOLXgMA0GCSqGSIb3DQEBBAUAA4GBAFWcg41Aoa1I+6etNhbr IILnoHF6lBPX99T9oOHDKEUcQmXpxpYcp1tJB7vu64UzWWN+P+1z0NY8nc/XASzQddmx56z8 Op0eOsinIsWIj5LZuo6WgExe0gck1wjgvmHyA+JVPIWTdS6kZ/t8I/95fOhPCR+jPT+EMNzM rHbfW9wcMIIDOTCCAqKgAwIBAgIBCjANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk4MDkxNjE3NTUzNFoXDTAw MDkxNTE3NTUzNFowgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDAS BgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UE CxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNjCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKXl1NTQXwgC7gchfSS/q2uOHusgBwIVhGuP0JMkHxud7miyuSxP6ZNn FxAXHqH5Q0EjuTCqdpe78+f9gcC1MYv2plAmVPKVKOsZpB6XHrDiuJvBBJoy0DwJbE/kNU/w dr8AEwNPRQhg8/y00JABihLJnLp/UuoqkzU2PDzkNS8CAwEAAaM3MDUwEgYDVR0TAQH/BAgw BgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQF AAOBgQAsx4IfAUM+B4/uaVypZIL4wJatkyvLm1DXQJqBwrqmdp08lUDcVcHhVYJ5qwopptUM 4VcoPo/5u9XfDZNYqlsti48z5N1YFTV2chUpvUL0WpILd1+dJ9uaLU4bggaO0o1Wu5Xe2wxl Bd6VngLdUxe+vvxrwxoiehQrYb3Cn156WjGCAdowggHWAgEBMIHAMIG5MQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UE ChMRVGhhd3RlIENvbnN1bHRpbmcxKTAnBgNVBAsTIFRoYXd0ZSBQRiBSU0EgSUsgMTk5OC45 LjE2IDE3OjU1MTYwNAYDVQQDEy1UaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgUlNBIElzc3Vl ciAxOTk4LjkuMTYCAlqsMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNOTkxMjA2MTUwNjM4WjAjBgkqhkiG9w0BCQQxFgQU+OshZf6L 5Pbjtk5mjaAYM/7LDXcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEQEWwMzT0FCcpyD/RlOFAXgdqlQnWDeWwGYNh7REOo3HeBndgQsb4I7pCSo+lLuZ0 av8czkV+RuwOEXyhu6X4rc8= --------------ms34E73F09BA8674A73111ABB2-- From owner-ipsec@lists.tislabs.com Mon Dec 6 08:56:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17933; Mon, 6 Dec 1999 08:56:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25000 Mon, 6 Dec 1999 10:06:37 -0500 (EST) Date: Mon, 6 Dec 1999 10:10:09 -0500 Message-Id: <199912061510.KAA01564@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kivinen@ssh.fi Cc: vilhuber@cisco.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> <199912060143.DAA21299@torni.ssh.fi> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> Jan Vilhuber writes: >> What about this: when sending a phase1-heartbeat (where we still >> need to agree what this would look like) from host A to host B, >> why not include in it all SPI's that host A shares with host B. If >> host B has a few SPI's that host A didn't include in the >> heartbeat, then they are obviously deleted, and host B should >> delete it's SPIS for those. Tero> That could be one way to do it, but it only allows machine to Tero> have 16376 SAs up at one time (64 kB packet limit at the UDP Tero> level). I have been doing testing with bigger number of SAs Tero> between hosts already now, and I wonder what amount of SAs we Tero> have in 5-10 years.... Tero> Is that amount enough? 16k SAs between a single pair of security gateways? The usual number is one. Indeed, there have been some good arguments why it's unlikely that much more than that is useful. (The classic argument for more is "so some data can be protected better than other". But with decent crypto performance, a simpler solution is to protect everything to the maximum extent possible.) Can you give a scenario where thousands of SAs between a single pair of security gateways is necessary? paul From owner-ipsec@lists.tislabs.com Mon Dec 6 09:37:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18392; Mon, 6 Dec 1999 09:37:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25171 Mon, 6 Dec 1999 10:50:22 -0500 (EST) Message-ID: <005c01bf3fff$55963160$9106b0d0@corp.certifiedtime.com> From: "Todd Glassey" To: "Tero Kivinen" , "Jan Vilhuber" Cc: "Andrew Krywaniuk" , References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> <199912060143.DAA21299@torni.ssh.fi> Subject: Re: Heartbeats (was RE: keepalives) Date: Mon, 6 Dec 1999 07:34:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Seems to me that the number of Keep-alives should be set by the Policy Control model of the specific site, and not by the protocol itself as a hard coded model. Keep-Alives are obviously very expensive on Overhead with the number of connection/session instances (in the non-uDP Sense) to be used, and therefore it should be left up the the Site as to how many they "choose" to expend resources (and thus money) to support. Or am I brain damaged again? Todd. ----- Original Message ----- From: "Tero Kivinen" To: "Jan Vilhuber" Cc: "Andrew Krywaniuk" ; Sent: Sunday, December 05, 1999 5:43 PM Subject: RE: Heartbeats (was RE: keepalives) > Jan Vilhuber writes: > > What about this: when sending a phase1-heartbeat (where we still need to > > agree what this would look like) from host A to host B, why not include in it > > all SPI's that host A shares with host B. If host B has a few SPI's that host > > A didn't include in the heartbeat, then they are obviously deleted, and host > > B should delete it's SPIS for those. > > That could be one way to do it, but it only allows machine to have > 16376 SAs up at one time (64 kB packet limit at the UDP level). I > have been doing testing with bigger number of SAs between hosts > already now, and I wonder what amount of SAs we have in 5-10 years.... > > Is that amount enough? > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Mon Dec 6 10:35:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19234; Mon, 6 Dec 1999 10:35:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25158 Mon, 6 Dec 1999 10:46:57 -0500 (EST) Message-ID: <384BDACF.FB80DB9F@ire-ma.com> Date: Mon, 06 Dec 1999 10:48:31 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: kivinen@ssh.fi, vilhuber@cisco.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> <199912060143.DAA21299@torni.ssh.fi> <199912061510.KAA01564@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, These are IPSec SAs Paul Koning wrote: > >>>>> "Tero" == Tero Kivinen writes: > > Tero> Jan Vilhuber writes: > >> What about this: when sending a phase1-heartbeat (where we still > >> need to agree what this would look like) from host A to host B, > >> why not include in it all SPI's that host A shares with host B. If > >> host B has a few SPI's that host A didn't include in the > >> heartbeat, then they are obviously deleted, and host B should > >> delete it's SPIS for those. > > Tero> That could be one way to do it, but it only allows machine to > Tero> have 16376 SAs up at one time (64 kB packet limit at the UDP > Tero> level). I have been doing testing with bigger number of SAs > Tero> between hosts already now, and I wonder what amount of SAs we > Tero> have in 5-10 years.... > > Tero> Is that amount enough? > > 16k SAs between a single pair of security gateways? The usual number > is one. Indeed, there have been some good arguments why it's unlikely > that much more than that is useful. (The classic argument for more is > "so some data can be protected better than other". But with decent > crypto performance, a simpler solution is to protect everything to the > maximum extent possible.) > > Can you give a scenario where thousands of SAs between a single pair > of security gateways is necessary? > > paul -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Mon Dec 6 10:35:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19247; Mon, 6 Dec 1999 10:35:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25462 Mon, 6 Dec 1999 11:52:59 -0500 (EST) From: jerome@psti.com Message-ID: <19991206115932.A26797@jerome.psti.com> Date: Mon, 6 Dec 1999 11:59:32 -0500 To: Mark Shuttleworth , ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec Reply-To: jerome@psti.com References: <384BD0FE.35DF2320@thawte.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: <384BD0FE.35DF2320@thawte.com>; from Mark Shuttleworth on Mon, Dec 06, 1999 at 10:06:38AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Dec 06, 1999 at 10:06:38AM -0500, Mark Shuttleworth wrote: > Will AES's primary advantage over 3DES be speed? it will be much faster and lets hope as secure. > I know that DES is now > considered weak... but that's because if its keyspace of 56 bits. Is > 3DES considered plenty strong but slow? yes > If you were wanting to protect > data for 50 years, would 3DES be good enough? it's hard to do prediction over so long time, but 3DES has a 168bits key. it is safe against a brute force attack. A cryptanalitic breakthrough is possible but not likely because DES is a well studied algrorithm and the basis of 3DES. From owner-ipsec@lists.tislabs.com Mon Dec 6 11:13:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23003; Mon, 6 Dec 1999 11:13:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25486 Mon, 6 Dec 1999 12:00:04 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: Mark Shuttleworth cc: ipsec@lists.tislabs.com Message-ID: <8525683F.005D841A.00@domino2.certicom.com> Date: Mon, 6 Dec 1999 08:56:40 -0800 Subject: Re: Incorporation of AES into IPSec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk aes will have speed and key size scalability over 3des. 3 key 3des provides 168-bits of symmetric privacy. aes will provide between 128-256-bits, but with a considerable speed advantage. both are extremely strong, but it doesn't really matter given that a 1,024-bit diffie-hellman is often used to negotiate the keys. 1,024-bit diffie-hellman or rsa is the equivalent of circa 80-bits of symmetric. i will email you a paper separately. cheers - john Mark Shuttleworth on 06.12.1999 07:06:38 To: ipsec@lists.tislabs.com cc: (bcc: John Harleman/Certicom) Subject: Re: Incorporation of AES into IPSec Hi all Will AES's primary advantage over 3DES be speed? I know that DES is now considered weak... but that's because if its keyspace of 56 bits. Is 3DES considered plenty strong but slow? If you were wanting to protect data for 50 years, would 3DES be good enough? -- Mark Shuttleworth Thawte From owner-ipsec@lists.tislabs.com Mon Dec 6 12:03:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28068; Mon, 6 Dec 1999 12:03:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25949 Mon, 6 Dec 1999 13:19:06 -0500 (EST) Date: Mon, 6 Dec 1999 13:21:53 -0500 (EST) From: Henry Spencer To: jerome@psti.com cc: Mark Shuttleworth , ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec In-Reply-To: <19991206115932.A26797@jerome.psti.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Dec 1999 jerome@psti.com wrote: > > If you were wanting to protect data for 50 years, would 3DES be good enough? > > it's hard to do prediction over so long time, but 3DES has a 168bits key. > it is safe against a brute force attack. Against a brute-force known-plaintext attack using meet-in-the-middle, 3DES's effective strength is only 112 bits, if the attacker can put a very large memory in the middle. However, 112 bits is still probably beyond reasonable attack on that time scale, barring major breakthroughs in computing technology. > A cryptanalitic breakthrough > is possible but not likely because DES is a well studied algrorithm > and the basis of 3DES. The one small worry here is that 3DES hasn't had nearly as much study as DES, and it's just possible that when you pile three copies of DES on top of each other, they interact in some way that weakens them. Agreed that this seems unlikely -- in particular, it's less likely than weaknesses in the various non-DES alternatives. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon Dec 6 12:12:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28651; Mon, 6 Dec 1999 12:12:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25970 Mon, 6 Dec 1999 13:25:19 -0500 (EST) Date: Mon, 6 Dec 1999 20:28:09 +0200 (EET) Message-Id: <199912061828.UAA22805@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Koning Cc: vilhuber@cisco.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: <199912061510.KAA01564@tonga.xedia.com> References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> <199912060143.DAA21299@torni.ssh.fi> <199912061510.KAA01564@tonga.xedia.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 20 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > 16k SAs between a single pair of security gateways? The usual number Not betwen gateways, between hosts. Usually that happens when you have SA per port type of policy (i.e. different policy per user). > Can you give a scenario where thousands of SAs between a single pair > of security gateways is necessary? Large unix machine with about 4096 users, each using AH+ESP (== 4 SAs pre tcp/ip connection), will give you more than 16k SAs... Having machine that has 4096 users logged in, isn't that common, but I wouldn't say it is impossible in 5 years... BTW, the other machine is of course the www-proxy or the firewall machine :-) Anyways I dont think it is common thing, but I say we should think about it at decide if we can accept such limit. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 6 12:15:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28908; Mon, 6 Dec 1999 12:15:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26026 Mon, 6 Dec 1999 13:45:05 -0500 (EST) Date: Mon, 6 Dec 1999 20:48:05 +0200 (EET) Message-Id: <199912061848.UAA09410@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: jerome@psti.com Cc: Mark Shuttleworth , ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec In-Reply-To: <19991206115932.A26797@jerome.psti.com> References: <384BD0FE.35DF2320@thawte.com> <19991206115932.A26797@jerome.psti.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk jerome@psti.com writes: > > If you were wanting to protect > > data for 50 years, would 3DES be good enough? > it's hard to do prediction over so long time, but 3DES has a 168bits key. > it is safe against a brute force attack. A cryptanalitic breakthrough No, 3DES do NOT have 168 bits of strength. Its effective strength is 112 bits, if you have 2^56 blocks of memory. You can find more information in the Applied Cryptography (Bruce Schneier, ISBN 0-471-11709-9) ) in section 15.2. There is also reference there to the following article: R.C. Merkle and M. Hellman, "On the Security of Multiple Encryption," Communications of the ACM, v.24, n. 7, 1981, pp. 465-467. which propably contains even more information... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 6 12:24:16 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29675; Mon, 6 Dec 1999 12:24:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26074 Mon, 6 Dec 1999 13:57:28 -0500 (EST) From: jerome@psti.com Message-ID: <19991206140407.A27437@jerome.psti.com> Date: Mon, 6 Dec 1999 14:04:07 -0500 To: Tero Kivinen Cc: Mark Shuttleworth , ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec Reply-To: jerome@psti.com References: <384BD0FE.35DF2320@thawte.com> <19991206115932.A26797@jerome.psti.com> <199912061848.UAA09410@torni.ssh.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: <199912061848.UAA09410@torni.ssh.fi>; from Tero Kivinen on Mon, Dec 06, 1999 at 08:48:05PM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Dec 06, 1999 at 08:48:05PM +0200, Tero Kivinen wrote: > jerome@psti.com writes: > > > If you were wanting to protect > > > data for 50 years, would 3DES be good enough? > > it's hard to do prediction over so long time, but 3DES has a 168bits key. > > it is safe against a brute force attack. A cryptanalitic breakthrough > > No, 3DES do NOT have 168 bits of strength. that's why i said a key of 168bits and not a strengh. > Its effective strength is 112 bits, if you have 2^56 blocks of memory. Ok, but 2^56 blocks of memory (2^29 GB) is a lot and is unlikely to be acceed fast enougth to performed 2^112 search in it in a reasonnable time. Moreover such amount of memory is harder to paralize than cpu-only brute force, so it will be shared by several cpus, creating lock problems and slowing down the overall search. From owner-ipsec@lists.tislabs.com Mon Dec 6 12:41:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00101; Mon, 6 Dec 1999 12:41:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26213 Mon, 6 Dec 1999 14:19:16 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Mon, 6 Dec 1999 11:22:22 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: <199912060143.DAA21299@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Dec 1999, Tero Kivinen wrote: > Jan Vilhuber writes: > > What about this: when sending a phase1-heartbeat (where we still need to > > agree what this would look like) from host A to host B, why not include in it > > all SPI's that host A shares with host B. If host B has a few SPI's that host > > A didn't include in the heartbeat, then they are obviously deleted, and host > > B should delete it's SPIS for those. > > That could be one way to do it, but it only allows machine to have > 16376 SAs up at one time (64 kB packet limit at the UDP level). I > have been doing testing with bigger number of SAs between hosts > already now, and I wonder what amount of SAs we have in 5-10 years.... > > Is that amount enough? I hadn't thought of that. Good point. A (shudder) 'more' bit? That would get unwieldly and complex with large numbers. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Dec 6 12:44:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00373; Mon, 6 Dec 1999 12:44:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26205 Mon, 6 Dec 1999 14:17:41 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Mon, 6 Dec 1999 11:20:50 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: Slava Kavsan , "Scott G. Kelly" , Srinivasa Rao Addepalli , Dan Harkins , Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation In-Reply-To: <199912060135.DAA27830@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Dec 1999, Tero Kivinen wrote: > Jan Vilhuber writes: > > On Fri, 3 Dec 1999, Tero Kivinen wrote: > > > We already have that "special" packet. It is called ICMP echo > > > (ping)... I don't think there is need to create another one. If we use > > > IPsec based keep-alives, I think it should use normal ICMP echo (ping) > > > packets. > > > > You can't do that, since that would run up the packet/byte counts, which some > > people want to do accounting on and charge the customer for. > > How about counting the bytes/packets only if they are routed through > the gateway, not if they are destinationed to the gateway. > Won't work either, since you might hav l2tp terminated in this box, so those packets don't get routed through the gateway, they terminate there (the contents get decapsulated and routed, but not the l2tp packets. > You have to do special code for the special packets for the accounting > anyways, so you can also detect that this is normal ping packet > destinationed to the gateway, and if so, do not add it to the counts. > If you use ping packets, and you are not doing accounting you don't > have to do anything special, everything works immediately. That's too much special casing in an already too complex protocol. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Dec 6 12:52:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00561; Mon, 6 Dec 1999 12:52:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26274 Mon, 6 Dec 1999 14:26:55 -0500 (EST) Date: Mon, 6 Dec 1999 21:30:05 +0200 (EET) Message-Id: <199912061930.VAA24353@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Jan Vilhuber Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: References: <199912060143.DAA21299@torni.ssh.fi> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > A (shudder) 'more' bit? That would get unwieldly and complex with large > numbers. We start thinking like that we propably should add something generic for IKE to allow larger packets. Like IKE over TCP/IP... The packet size limit is because of UDP, the IKE itself allows the total packet length of 4 GB, and each payload must be less than 64 kB. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 6 13:43:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01260; Mon, 6 Dec 1999 13:43:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26564 Mon, 6 Dec 1999 14:52:40 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242DC0@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Slava Kavsan'" Cc: ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Mon, 6 Dec 1999 11:56:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is not evident that it is a good idea to used Acked-NOTIFY or any other Acked message for this function. If the traffic is protected by some key, and if he adversary somehow knows it is being used (e.g., because the traffic is remote access), then inserting an Ack into the protocol transforms the peer into an oracle to answer questions about the key--the adversary knows it has guessed the right key as soon as it can get one system to ack to its "keepalive". If this observation is correct, then what seems to be needed is for one end to apprise its peer that it (the local system) may purge old SAs that appear to have died, along with some notion of what it considers dead (e.g., it receives no traffic for 5 minutes). It then becomes the responsibility of the peer that wants its SAs to remain to send traffic to defeat the dead SA harvesting. So any solution should propose mechanisms for both parts. -- Jesse -----Original Message----- From: Slava Kavsan [mailto:bkavsan@ire-ma.com] Sent: Friday, December 03, 1999 8:04 AM To: Scott G. Kelly Cc: Jan Vilhuber; Srinivasa Rao Addepalli; Dan Harkins; Markku Savela; ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation "Scott G. Kelly" wrote: > Maybe dead peer detection should not rely upon the presence of an IKE > SA. I like this approach, but it needs to be further analysed: - are there any attacks possible when using unprotected NOTIFYes for keep-alive? E.g. is "false-alive" attack is really an attack? - what if protected keep-alives are used when possible (IKE SA is around) and non-protected when there is no IKE SA? - use of keep-alives in this fashion will prevent us from taking advantage of using Ack-ed NOTIFY for keep-alives, because Ack-ed NOTIFY is always protected (unless this requirement can be relaxed for keep-alives) - could resource-minded implementations when they need more memory "shrink" their SAs (instead of deleting them) to a bare minimum to only support keep-alive protection? - could we use (somehow) IPSec-based keep-alives - etc. - etc. From owner-ipsec@lists.tislabs.com Mon Dec 6 13:43:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01262; Mon, 6 Dec 1999 13:43:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26520 Mon, 6 Dec 1999 14:44:10 -0500 (EST) Message-ID: <384C1373.93F397BE@ibondinc.com> Date: Mon, 06 Dec 1999 11:50:11 -0800 From: Srinivasa Rao Addepalli X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: kivinen@ssh.fi, vilhuber@cisco.com, akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> <199912060143.DAA21299@torni.ssh.fi> <199912061510.KAA01564@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > >>>>> "Tero" == Tero Kivinen writes: > > Tero> Jan Vilhuber writes: > >> What about this: when sending a phase1-heartbeat (where we still > >> need to agree what this would look like) from host A to host B, > >> why not include in it all SPI's that host A shares with host B. If > >> host B has a few SPI's that host A didn't include in the > >> heartbeat, then they are obviously deleted, and host B should > >> delete it's SPIS for those. > > Tero> That could be one way to do it, but it only allows machine to > Tero> have 16376 SAs up at one time (64 kB packet limit at the UDP > Tero> level). I have been doing testing with bigger number of SAs > Tero> between hosts already now, and I wonder what amount of SAs we > Tero> have in 5-10 years.... > > Tero> Is that amount enough? > > 16k SAs between a single pair of security gateways? The usual number > is one. Indeed, there have been some good arguments why it's unlikely > that much more than that is useful. (The classic argument for more is > "so some data can be protected better than other". But with decent > crypto performance, a simpler solution is to protect everything to the > maximum extent possible.) > > Can you give a scenario where thousands of SAs between a single pair > of security gateways is necessary? These are phase2 SAs and their number can be big if same gateways are providing LAN-to-LAN connectivity. Phase 2 SAs are created for differnet combinations of IP addresses and Ports,so they can be large. In some implementations, memory is very premium and it may be very difficult to send bigger UDP packets. In some implementations, all the UDP data needs to be sent to the TCP/IP stack at once, and it may not be able to allocate 64K byte memory block to store all the phase2 SAs SPIs. I feel, it is better to indicate which SAs are alive in the sender side in more than one packet and at different times. On receiving side, if it does not receive any keep alives for certain period of time for SAs, then it will delete them. > > > paul Regards Srini From owner-ipsec@lists.tislabs.com Mon Dec 6 13:43:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01280; Mon, 6 Dec 1999 13:43:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26614 Mon, 6 Dec 1999 15:01:17 -0500 (EST) Message-ID: <384C1670.D8B25E1C@ire-ma.com> Date: Mon, 06 Dec 1999 15:02:56 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Walker, Jesse" CC: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation References: <392A357CE6FFD111AC3E00A0C99848B002242DC0@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Very interesting point Jesse! In other words - someone could use encrypted keep-alive messages for brute-force key discovery? Well - this may take gazillion years to attack - hopefully IKE SA lifetimes are shorter than that :)) "Walker, Jesse" wrote: > It is not evident that it is a good idea to used Acked-NOTIFY or any other > Acked message for this function. If the traffic is protected by some key, > and if he adversary somehow knows it is being used (e.g., because the > traffic is remote access), then inserting an Ack into the protocol > transforms the peer into an oracle to answer questions about the key--the > adversary knows it has guessed the right key as soon as it can get one > system to ack to its "keepalive". > > If this observation is correct, then what seems to be needed is for one end > to apprise its peer that it (the local system) may purge old SAs that appear > to have died, along with some notion of what it considers dead (e.g., it > receives no traffic for 5 minutes). It then becomes the responsibility of > the peer that wants its SAs to remain to send traffic to defeat the dead SA > harvesting. So any solution should propose mechanisms for both parts. > > -- Jesse > > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: Friday, December 03, 1999 8:04 AM > To: Scott G. Kelly > Cc: Jan Vilhuber; Srinivasa Rao Addepalli; Dan Harkins; Markku Savela; > ipsec@lists.tislabs.com > Subject: Re: IPSec SA DELETE in "dangling" implementation > > "Scott G. Kelly" wrote: > > > Maybe dead peer detection should not rely upon the presence of an IKE > > SA. > > I like this approach, but it needs to be further analysed: > > - are there any attacks possible when using unprotected NOTIFYes for > keep-alive? E.g. is > "false-alive" attack is really an attack? > - what if protected keep-alives are used when possible (IKE SA is around) > and non-protected > when there is no IKE SA? > - use of keep-alives in this fashion will prevent us from taking advantage > of using Ack-ed > NOTIFY for keep-alives, because Ack-ed NOTIFY is always protected (unless > this requirement can > be relaxed for keep-alives) > - could resource-minded implementations when they need more memory "shrink" > their SAs (instead > of deleting them) to a bare minimum to only support keep-alive protection? > - could we use (somehow) IPSec-based keep-alives > - etc. > - etc. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Mon Dec 6 13:43:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01282; Mon, 6 Dec 1999 13:43:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26580 Mon, 6 Dec 1999 14:56:41 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Mon, 6 Dec 1999 11:59:46 -0800 (PST) From: Jan Vilhuber To: Tero Kivinen cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: <199912061930.VAA24353@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Dec 1999, Tero Kivinen wrote: > Jan Vilhuber writes: > > A (shudder) 'more' bit? That would get unwieldly and complex with large > > numbers. > > We start thinking like that we propably should add something generic > for IKE to allow larger packets. Like IKE over TCP/IP... > Yes. > The packet size limit is because of UDP, the IKE itself allows the > total packet length of 4 GB, and each payload must be less than 64 kB. Maybe it would be worth doing, and simply accepting the fact that if you have a situation where your packet size is no longer sufficient to handle the number of SA's between your two gateways, then you need to look at other transport media. So if you run out, you'll have to look at a TCP/IP implementation of IKE instead of UDP. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Dec 6 14:21:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01802; Mon, 6 Dec 1999 14:21:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26692 Mon, 6 Dec 1999 15:19:21 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242DC1@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Slava Kavsan'" Cc: ipsec@lists.tislabs.com Subject: RE: IPSec SA DELETE in "dangling" implementation Date: Mon, 6 Dec 1999 12:22:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The adversary may not need a gazillion years; they may have (much) better information, and she may only need to brute-force a few remaining bits. If IKE group 2 is used, for instance, only the upper 10 bits of the Diffie-Hellman are known to be hard-core; if it is possible to easily compute the rest of the bits from the public Diffie-Hellman exponents, then only 1024/2 = 512 queries would be needed on average to break the key. -- Jesse -----Original Message----- From: Slava Kavsan [mailto:bkavsan@ire-ma.com] Sent: Monday, December 06, 1999 12:03 PM To: Walker, Jesse Cc: ipsec@lists.tislabs.com Subject: Re: IPSec SA DELETE in "dangling" implementation Very interesting point Jesse! In other words - someone could use encrypted keep-alive messages for brute-force key discovery? Well - this may take gazillion years to attack - hopefully IKE SA lifetimes are shorter than that :)) "Walker, Jesse" wrote: > It is not evident that it is a good idea to used Acked-NOTIFY or any other > Acked message for this function. If the traffic is protected by some key, > and if he adversary somehow knows it is being used (e.g., because the > traffic is remote access), then inserting an Ack into the protocol > transforms the peer into an oracle to answer questions about the key--the > adversary knows it has guessed the right key as soon as it can get one > system to ack to its "keepalive". > > If this observation is correct, then what seems to be needed is for one end > to apprise its peer that it (the local system) may purge old SAs that appear > to have died, along with some notion of what it considers dead (e.g., it > receives no traffic for 5 minutes). It then becomes the responsibility of > the peer that wants its SAs to remain to send traffic to defeat the dead SA > harvesting. So any solution should propose mechanisms for both parts. > > -- Jesse > > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: Friday, December 03, 1999 8:04 AM > To: Scott G. Kelly > Cc: Jan Vilhuber; Srinivasa Rao Addepalli; Dan Harkins; Markku Savela; > ipsec@lists.tislabs.com > Subject: Re: IPSec SA DELETE in "dangling" implementation > > "Scott G. Kelly" wrote: > > > Maybe dead peer detection should not rely upon the presence of an IKE > > SA. > > I like this approach, but it needs to be further analysed: > > - are there any attacks possible when using unprotected NOTIFYes for > keep-alive? E.g. is > "false-alive" attack is really an attack? > - what if protected keep-alives are used when possible (IKE SA is around) > and non-protected > when there is no IKE SA? > - use of keep-alives in this fashion will prevent us from taking advantage > of using Ack-ed > NOTIFY for keep-alives, because Ack-ed NOTIFY is always protected (unless > this requirement can > be relaxed for keep-alives) > - could resource-minded implementations when they need more memory "shrink" > their SAs (instead > of deleting them) to a bare minimum to only support keep-alive protection? > - could we use (somehow) IPSec-based keep-alives > - etc. > - etc. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Mon Dec 6 15:01:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02569; Mon, 6 Dec 1999 15:01:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26863 Mon, 6 Dec 1999 16:11:15 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: jerome@psti.com cc: ipsec@lists.tislabs.com (bcc: John Harleman/Certicom) Message-ID: <8525683F.0073C5E7.00@domino2.certicom.com> Date: Mon, 6 Dec 1999 13:09:44 -0800 Subject: Re: Incorporation of AES into IPSec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk estimating the strength of an algorithm depends on the best known attack. when i say 80-bits of symmetric, i mean a symmetric algorithm that the best known attacks are exponential and thus, it provides a true 80-bits of key strength. on the public-key side, the best known attacks against rsa and diffie-hellman are subexponential and based upon calculations, one can determine approximate time to break (see the paper). this is not an exact science, but an approximation when matching the time it takes to break one with the time it takes to break the other. thus the circa. cheers - john jerome@psti.com on 06.12.1999 11:34:30 Please respond to jerome@psti.com To: John Harleman/Certicom@Certicom cc: Subject: Re: Incorporation of AES into IPSec On Mon, Dec 06, 1999 at 08:56:40AM -0800, John Harleman wrote: > aes will have speed and key size scalability over 3des. 3 key 3des provides > 168-bits of symmetric privacy. aes will provide between 128-256-bits, but with a > considerable speed advantage. both are extremely strong, but it doesn't really > matter given that a 1,024-bit diffie-hellman is often used to negotiate the > keys. 1,024-bit diffie-hellman or rsa is the equivalent of circa 80-bits of > symmetric. i will email you a paper separately. cheers - john what do you call a circa 80bits of symmetric ? especially "circa" From owner-ipsec@lists.tislabs.com Mon Dec 6 15:19:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03233; Mon, 6 Dec 1999 15:19:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26944 Mon, 6 Dec 1999 16:35:34 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: Tero Kivinen cc: jerome@psti.com, Mark Shuttleworth , ipsec@lists.tislabs.com Message-ID: <8525683F.0076BDD8.00@domino2.certicom.com> Date: Mon, 6 Dec 1999 13:40:56 -0800 Subject: Re: Incorporation of AES into IPSec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero: No, 3DES do NOT have 168 bits of strength. Tero: Its effective strength is 112 bits, if you Tero: have 2^56 blocks of memory. You can find more Tero: information in the Applied Cryptography Tero: (Bruce Schneier, ISBN 0-471-11709-9) ) in Tero: section 15.2. triple des can support two key sizes--two key or three key. 2key triple des=112-bits of symmetric strength, 3key triple des=168-bits. cheers - john Tero Kivinen on 06.12.1999 10:48:05 To: jerome@psti.com cc: Mark Shuttleworth , ipsec@lists.tislabs.com (bcc: John Harleman/Certicom) Subject: Re: Incorporation of AES into IPSec jerome@psti.com writes: > > If you were wanting to protect > > data for 50 years, would 3DES be good enough? > it's hard to do prediction over so long time, but 3DES has a 168bits key. > it is safe against a brute force attack. A cryptanalitic breakthrough No, 3DES do NOT have 168 bits of strength. Its effective strength is 112 bits, if you have 2^56 blocks of memory. You can find more information in the Applied Cryptography (Bruce Schneier, ISBN 0-471-11709-9) ) in section 15.2. There is also reference there to the following article: R.C. Merkle and M. Hellman, "On the Security of Multiple Encryption," Communications of the ACM, v.24, n. 7, 1981, pp. 465-467. which propably contains even more information... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 6 16:55:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10525; Mon, 6 Dec 1999 16:55:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27368 Mon, 6 Dec 1999 18:30:35 -0500 (EST) Message-Id: <4.2.1.19991206153415.00c79bb0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 06 Dec 1999 15:36:16 -0800 To: "John Harleman" , Tero Kivinen From: Paul Hoffman Subject: Re: Incorporation of AES into IPSec Cc: jerome@psti.com, Mark Shuttleworth , ipsec@lists.tislabs.com In-Reply-To: <8525683F.0076BDD8.00@domino2.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, is this really the right forum for this discussion? The question was "will IPsec do AES" and the answer was "most likely yes when AES is finalized". Arguments about the technical merits of TripleDES (which is *still* not a required algorithm...) should be held on crypto lists, I believe. If you think they're important for the IETF, maybe hold them on the SAAG mailing list. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Dec 6 17:54:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA11690; Mon, 6 Dec 1999 17:54:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27319 Mon, 6 Dec 1999 18:21:35 -0500 (EST) Date: Mon, 6 Dec 1999 18:24:30 -0500 (EST) From: Henry Spencer To: John Harleman cc: ipsec@lists.tislabs.com Subject: Re: Incorporation of AES into IPSec In-Reply-To: <8525683F.0076BDD8.00@domino2.certicom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Dec 1999, John Harleman wrote: > triple des can support two key sizes--two key or three key. 2key triple > des=112-bits of symmetric strength, 3key triple des=168-bits. IPSEC uses only the 3-key form, which has only 112 bits of strength against meet-in-the-middle attacks. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon Dec 6 23:17:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA12733; Mon, 6 Dec 1999 23:17:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28863 Tue, 7 Dec 1999 01:05:44 -0500 (EST) Date: Tue, 7 Dec 1999 15:09:13 +0900 (JST) From: Shoichi Sakane Message-Id: <199912070609.PAA02770@ghost.wide.ydc.co.jp> To: ipsec@lists.tislabs.com Subject: interpretation of SA bundle. X-Mailer: Cue version 0.6 (991206-0337/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I may be missing something, but I don't know how to interpret a proposal of SA bundle exchanged on phase 2. Node A sends a proposal including AH tunnel mode followed by ESP tunnel mode. In this case, we should interpreted to be created IP payload by using this SA, 1. [outer IP][AH][ESP][inner IP][ULP] 2. [outer IP][ESP][AH][inner IP][ULP] 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP] 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP] Which is right ? Another case, Node A sends a proposal including AH transport mode followed by ESP tunnel mode. 1. [outer IP][AH][ESP][inner IP][ULP] 2. [outer IP][ESP][inner IP][AH][ULP] I think there is not these rules of interpretation in any drafts. Regareds, /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Mon Dec 6 23:18:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA12796; Mon, 6 Dec 1999 23:18:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28864 Tue, 7 Dec 1999 01:05:44 -0500 (EST) Date: Tue, 7 Dec 1999 15:09:13 +0900 (JST) From: Shoichi Sakane Message-Id: <199912070609.PAA02773@ghost.wide.ydc.co.jp> To: ipsec@lists.tislabs.com Subject: ID payload on phase 2. X-Mailer: Cue version 0.6 (991206-0337/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi folks, Let me know my questions. Which IP address is included in ID payload on Phase 2 ? Draft says that If there is no ID payload, then ID is the IP address of the IKE peers. But I'm confusing if there is ID payload. Assumed that we will create the SAs between SG1 and SG2. In section 6.2 in draft-ietf-ipsec-ike-01.txt, 5th paragraph means: 1. IDi2, IDr2 means which nodes having the IP address are protected by the SAs. IDi2 ----- SG1 ====== SG2 ----- IDr2 or SG1(IDi2) ====== SG2(IDr2) 2. IDi2, IDr2 means the IP address of the end of the IPsec-SA. X ----- SG1(IDi2) ===== SG2(IDr2)----- Y I think #1 is right because ID is used to decide acceptable proposal. If so, I will have next question. Which is IP address used as the IP address of the end of the IPsec-SA ? Is the end of the IKE-SA's IP address always same to the IPsec-SA's ? If node has some IP address, then is there a potential that multiple SA based IP address is created, but same nodes are communicating ? node A node B IPa1 ---- SA1 ----> IPb IPa2 ---- SA2 ----> IPb IPa3 ---- SA3 ----> IPb I think it is useful something if the IKE peers can exchange the end of the IP address of IPsec-SA on phase 2. Regareds, /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Tue Dec 7 01:27:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17882; Tue, 7 Dec 1999 01:27:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA29174 Tue, 7 Dec 1999 02:04:09 -0500 (EST) Message-Id: <199912070705.XAA04067@potassium.network-alchemy.com> To: Shoichi Sakane cc: ipsec@lists.tislabs.com Subject: Re: ID payload on phase 2. In-reply-to: Your message of "Tue, 07 Dec 1999 15:09:13 +0900." <199912070609.PAA02773@ghost.wide.ydc.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4064.944550321.1@network-alchemy.com> Date: Mon, 06 Dec 1999 23:05:22 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The ID payload describes the selector for which IP packets will be applied some IPSec transforms. If your selector is for all TCP packets between net 10.10.10/24 and host 10.20.20.2 then that is what would be conveyed in the ID payloads during phase 2. IKE would've been started because there were no IPSec SAs for TCP packets from 10.10.10/24 to 10.20.20.2 and once an IKE SA is established with 10.20.20.2 from the gateway which protects 10.10.10/24 that gateway would initiate a phase 2 exchange with IDs for 10.10.10/24/tcp/0 and 10.20.20.2/tcp/0. Dan. On Tue, 07 Dec 1999 15:09:13 +0900 you wrote > Hi folks, Let me know my questions. > > Which IP address is included in ID payload on Phase 2 ? Draft says that > If there is no ID payload, then ID is the IP address of the IKE peers. > But I'm confusing if there is ID payload. > > Assumed that we will create the SAs between SG1 and SG2. In section 6.2 > in draft-ietf-ipsec-ike-01.txt, 5th paragraph means: > > 1. IDi2, IDr2 means which nodes having the IP address are > protected by the SAs. > IDi2 ----- SG1 ====== SG2 ----- IDr2 > or > SG1(IDi2) ====== SG2(IDr2) > > 2. IDi2, IDr2 means the IP address of the end of the IPsec-SA. > X ----- SG1(IDi2) ===== SG2(IDr2)----- Y > > I think #1 is right because ID is used to decide acceptable proposal. > If so, I will have next question. Which is IP address used as the IP > address of the end of the IPsec-SA ? > Is the end of the IKE-SA's IP address always same to the IPsec-SA's ? > If node has some IP address, then is there a potential that multiple SA > based IP address is created, but same nodes are communicating ? > > node A node B > IPa1 ---- SA1 ----> IPb > IPa2 ---- SA2 ----> IPb > IPa3 ---- SA3 ----> IPb > > I think it is useful something if the IKE peers can exchange the end of > the IP address of IPsec-SA on phase 2. > > Regareds, > > /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Tue Dec 7 02:58:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18974; Tue, 7 Dec 1999 02:58:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA29434 Tue, 7 Dec 1999 03:24:08 -0500 (EST) Date: Tue, 7 Dec 1999 10:12:33 +0200 (EET) From: Markku Savela Message-Id: <199912070812.KAA20447@anise.tte.vtt.fi> To: sakane@ydc.co.jp CC: ipsec@lists.tislabs.com In-reply-to: <199912070609.PAA02770@ghost.wide.ydc.co.jp> (message from Shoichi Sakane on Tue, 7 Dec 1999 15:09:13 +0900 (JST)) Subject: Re: interpretation of SA bundle. Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My interpretation... > Node A sends a proposal including AH tunnel mode followed by ESP tunnel > mode. In this case, we should interpreted to be created IP payload by > using this SA, > > 1. [outer IP][AH][ESP][inner IP][ULP] > 2. [outer IP][ESP][AH][inner IP][ULP] > 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP] > 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP] > > Which is right ? Assuming the proposal order as you stated: 4 (e.g. first apply tunnel+AH, then tunnel+ESP). Note, in (1) AH and in (2) ESP is transport mode, so they don't match your proposal anyway. The result should depend on the ordering in the proposal? I don't know about IKE, but I can express all of the above combinations in my policy file, and the kernel IPSEC machinery can do them. > Another case, Node A sends a proposal including AH transport mode followed > by ESP tunnel mode. > > 1. [outer IP][AH][ESP][inner IP][ULP] > 2. [outer IP][ESP][inner IP][AH][ULP] > > I think there is not these rules of interpretation in any drafts. The case 2 (e.g. first apply AH, then tunnel+ESP). I guess the rule should just state: apply strictly in proposed order. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Tue Dec 7 07:30:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26281; Tue, 7 Dec 1999 07:30:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00227 Tue, 7 Dec 1999 08:50:30 -0500 (EST) To: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Tue, 7 Dec 1999 12:20:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CFFE3@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been looking into this privately, as I'm sure a lot of people must have. We wanted a heartbeat functions as much for resilience as much as tidying up resource - you can't fall back to a secondary GW until you detect that the primary GW has failed. We also want to time out unused connections, so the heartbeat shouldn't interfere with this function. A naive heartbeat implementation could keep an SA rekeying indefinitely. Somewhat related to the last question is dial-up. If the GW is sitting on the other side of an, eg, ISDN link the heartbeat shouldn't keep up the link indefinitely. This shouldn't be such an issue for permanent links - the overhead of the heartbeat should be minimal. I think there will need to be different behaviour for permanent and dial-up links. The purpose of the heartbeat should be to determine that the peer is still active and communicating. This can be deduced as long as you continue to receive authenticated traffic from the peer. I think this means that heartbeats are not required as long as regular IPSEC protected traffic is being received from the peer. In the absence of regular traffic to a peer, heartbeats should be transmitted at regular configurable intervals. In these circumstances a connection can be considered dead if no traffic is received within a configurable interval. I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or 'hijacked' tunnelled ESP. I think this is a new protocol but I don't think it justifies an SA of its own. I think using an ISAKMP notification is best as most people seem to want this associated with the phase 1 SA. The ISDN scenario is rather harder to crack. My thoughts on this are if the customer really doesn't want his line brought up for crypto-management then the keep-alive mechanism should function just briefly after regular traffic is transmitted. Chris From owner-ipsec@lists.tislabs.com Tue Dec 7 07:30:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26333; Tue, 7 Dec 1999 07:30:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00197 Tue, 7 Dec 1999 08:38:46 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFCE74@exchange> From: Tim Jenkins To: msa@hemuli.tte.vtt.fi, sakane@ydc.co.jp Cc: ipsec@lists.tislabs.com Subject: RE: interpretation of SA bundle. Date: Tue, 7 Dec 1999 08:44:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Markku Savela [mailto:msa@anise.tte.vtt.fi] > Sent: December 7, 1999 3:13 AM > To: sakane@ydc.co.jp > Cc: ipsec@lists.tislabs.com > Subject: Re: interpretation of SA bundle. > > > My interpretation... > > > Node A sends a proposal including AH tunnel mode followed by ESP > tunnel > > mode. In this case, we should interpreted to be created IP > payload by > > using this SA, > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > 2. [outer IP][ESP][AH][inner IP][ULP] > > 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP] > > 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP] > > > > Which is right ? > > Assuming the proposal order as you stated: 4 (e.g. first apply > tunnel+AH, then tunnel+ESP). Note, in (1) AH and in (2) ESP is > transport mode, so they don't match your proposal anyway. > > The result should depend on the ordering in the proposal? I don't know > about IKE, but I can express all of the above combinations in my > policy file, and the kernel IPSEC machinery can do them. > First, let's be explicit about how this was proposed. If this was proposed as a single SA payload with multiple proposal payloads with the same number, then: We discussed this and tested this at a bake-offs quite some time ago and the concensus seemed to be that the order of application was not as proposed, but as to what made sense. That order was (outbound processing) IPCOMP before ESP before AH, no matter what the order of proposal. Secondly, the attributes across the proposals are to be consistent, and that they must apply to the bundle as a whole. [Aside: this is specifically called an SA suite in the MIBs.] This means that a bundle (of this type) is all transport mode or all tunnel mode. This means that the correct answer for the above questions is 1. > > Another case, Node A sends a proposal including AH transport mode > followed > > by ESP tunnel mode. > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > 2. [outer IP][ESP][inner IP][AH][ULP] > > > > I think there is not these rules of interpretation in any drafts. > > The case 2 (e.g. first apply AH, then tunnel+ESP). I guess the rule > should just state: apply strictly in proposed order. Again, with the same assumptions, the second case is inconsistent. However, our implementation will convert the transport mode to tunnel, and apply tunnel to the whole thing. Therefore, the answer is 1. I third the suggestion that this needs to be clearer. Our implementation originally did what Markku's did. It no longer does. From owner-ipsec@lists.tislabs.com Tue Dec 7 12:38:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02504; Tue, 7 Dec 1999 12:38:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01371 Tue, 7 Dec 1999 13:32:26 -0500 (EST) Message-ID: <384D5390.5B41A6B1@redcreek.com> Date: Tue, 07 Dec 1999 10:36:00 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <1FD60AE4DB6CD2118C420008C74C27B81CFFE3@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or > 'hijacked' tunnelled ESP. I think this is a new protocol but I don't think > it justifies an SA of its own. I think using an ISAKMP notification is best > as most people seem to want this associated with the phase 1 SA. I'd like to see dead peer detection be in a dedicated IPsec SA pair per peer pair. There are several good things about doing dead peer detection this way: * If there are multiple IKE or IPsec SAs to same peer, only need one 'keepalive' session. * Allows IKE SAs to go away (or dangle the IPsec SAs) if an implementation so wishes. * Does not interfere with packet counts or inactivity time outs of IKE or other IPsec SAs. * IPsec may architecturally swap key management protocol without worrying about loosing dead peer detection functions. * may be enabled or disabled per peer by policy Here is one negative that I can think of: If one peer reconfigures such that some but not all current IPsec SAs become defunct, this scheme may not detect that or may think all current SAs became defunct. This could be engineered around with a dead peer recovery detection algorithm. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Tue Dec 7 14:14:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05185; Tue, 7 Dec 1999 14:14:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01770 Tue, 7 Dec 1999 15:39:34 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Tue, 7 Dec 1999 12:43:03 -0800 Message-Id: Subject: A fix for main mode with preshared keys MIME-Version: 1.0 To: ipsec@lists.tislabs.com Content-Type: text/plain; charset=US-ASCII; name="cc:Mail" Content-Disposition: inline; filename="cc:Mail" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I propose below a very simple fix for the following problem, which has been pointed out by many people: in main mode with preshared keys, the responder cannot decrypt IDii, the initiator's identity payload, unless the responder knows the preshared key, which in turn depends on the initiator's identity. Two workarounds have been proposed: (1) The use of the source-IP-address field in IP packets as identity, rather than the ID payload, at least in this case. (2) The introduction of a completely new mode with different security properties ("IKE Base Mode", Internet draft by Yael Dayan and Sara Bitan). In my opinion, (1) is a bad idea for the following reasons: - It goes against the spirit of the ISAKMP and IPSEC protocols. For example, ISAKMP has an Identity Protection exchange, of which Main Mode is an instance. This exchange protects the identities of the parties carried in the ID payload. Ignoring the ID payload and using instead the source IP address in the packets defeats the nominal purpose (identity protection) of the exchange. As another example, RFC 2407 (DOI), Section 4.6.2, says "The Identification Payload is used to identify the initator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association." - It introduces ambiguities and creates confusion. (When should the ID payload be used for identification? When should the source IP address be used instead? Should both be used for different identification purposes? If both are different, should identification fail? If a certificate is used, should it certify the ID payload, or the source IP address, or both? Solving all these questions could take years...) - It introduces a special case, which reduces the quality of the protocol, and increases its complexity. - It doesn't work in cases where IP addresses are assigned dynamically, such as remote access. The proposed IKE Base Mode would be a useful addition to IKE because it is based on the ISAKMP Base Exchange, which provides a different set of security tradeoffs than those available in the Identity Protection Exchange (Main Mode) and the Aggressive Exchange (Aggressive Mode). Specifically, it provides some protection against DoS and allows for negotiation of the DH group, while sacrificing identity protection. However Base Mode does not solve the problem. It remains impossible to provide identity protection (the nominal goal of the Identity Protection exchange used by Main Mode) while using preshared keys. The problem comes from the fact that keying material (SKEYID_d, SKEYID_a and SKEYID_e) is derived from two different sources: the Diffie-Hellman secret g^xy, and the secret used for authentication. This is so in the case of authentication by preshared key, as well as in the case of authentication by public key encryption. But there is no reason why the keying material should be derived from these two sources. In other protocols that use ephemeral Diffie-Hellman, the keying material is derived only from the Diffie-Hellman secret. So I'd like to propose that we derive the keying material exclusively from the Diffie-Hellman secret. One way of doing this with minimal change to the existing protocol is simply to change SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) to SKEYID_d = hash(g^xy | CKY-I | CKY-R | 0) SKEYID_a = hash(SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = hash(SKEYID_a | g^xy | CKY-I | CKY-R | 2) I believe this solves the problem. Note that there is a related problem mentioned in RFC 2409, Section 5.4: When using pre-shared key authentication with Main Mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. However this is not a real problem for the following reasons. First, the initiator should know who it wants to communicate with, and therefore should be able to determine the preshared key. Granted, the *IKE code* may not know, but this is a software architecture issue rather than a protocol problem. Secondly, the responder does not have this problem (assuming that the above fix has been applied, and the responder can decrypt IDii). The remote access problem is then solved as follows: - The remote client initiates contact with the security gateway at a known, fixed IP address. IKE on the remote client can find the preshared key based on this address, or else the remote access code can obtain the preshared key from the user and pass it to IKE. IKE uses it to compute HASH_I before sending the 5th message in the Main Mode exchange. - The remote client has a dynamically assigned IP address, but it identifies itself using, for example, a fully-qualified username (ID_USER_FQDN in the DOI) in the IDii payload. After the gateway receives and decrypts the payload, it looks up the corresponding preshared key and uses it compute HASH_R before sending the 6th message of the exchange. Francisco Corella (francisco_corella@hp.com) From owner-ipsec@lists.tislabs.com Tue Dec 7 14:34:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05477; Tue, 7 Dec 1999 14:34:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01923 Tue, 7 Dec 1999 16:11:09 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 7 Dec 1999 13:14:12 -0800 (PST) From: Jan Vilhuber To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: <384D5390.5B41A6B1@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Dec 1999, Ricky Charlet wrote: > > > I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or > > 'hijacked' tunnelled ESP. I think this is a new protocol but I don't think > > it justifies an SA of its own. I think using an ISAKMP notification is best > > as most people seem to want this associated with the phase 1 SA. > > > > I'd like to see dead peer detection be in a dedicated IPsec SA pair per > peer pair. There are several good things about doing dead peer detection > this way: > This would require a new DOI, no? It's a dedicated phase 2 SA, but it's not (I claim) an ipsec SA. So a new DOI is needed. jan > * If there are multiple IKE or IPsec SAs to same peer, only need one > 'keepalive' session. > > * Allows IKE SAs to go away (or dangle the IPsec SAs) if an > implementation so wishes. > > * Does not interfere with packet counts or inactivity time outs of IKE > or other IPsec SAs. > > * IPsec may architecturally swap key management protocol without > worrying about loosing dead peer detection functions. > > * may be enabled or disabled per peer by policy > > > > Here is one negative that I can think of: If one peer reconfigures such > that some but not all current IPsec SAs become defunct, this scheme may > not detect that or may think all current SAs became defunct. This could > be engineered around with a dead peer recovery detection algorithm. > > -- > #################################### > # Ricky Charlet > # (510) 795-6903 > # rcharlet@redcreek.com > #################################### > > end Howdy; > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Dec 7 14:54:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06039; Tue, 7 Dec 1999 14:54:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02072 Tue, 7 Dec 1999 16:42:57 -0500 (EST) Message-Id: <199912072144.NAA05781@potassium.network-alchemy.com> To: francisco_corella@hp.com cc: ipsec@lists.tislabs.com Subject: Re: A fix for main mode with preshared keys In-reply-to: Your message of "Tue, 07 Dec 1999 12:43:03 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5778.944603070.1@network-alchemy.com> Date: Tue, 07 Dec 1999 13:44:30 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This approach has been proposed (and rejeted) in the past. If you want to use pre-shared keys and have identity protection then use either base mode or aggressive mode with ID_KEY_ID-type identities. This is an opaque blob that is not meaningful to an evesdropper. For example, the pre-shared key database could be: ID_KEY_ID value "real" identity pre-shared key ---------------- ----------------- ---------------- tr8gsnkdru8gsw Barney Gumble mekmitasdigoat dfnmtynioghora Ned Flanders whatcertificatereally etc. So if an entity sends an ID whose type is ID_KEY_ID and whose value is tr8gsnkdru8gsw and can also prove knowledge of the pre-shared key then that person is believed to be Barney Gumble. The "real" identity is never transmitted. For those of you who are concerned about massive evesdropping on the Internet and tracking of opaque blobs ("dfnmtynioghora was in Grozny on Tuesday and Khartoum on Thursday, it _must_ Osama Bin Laden! Next time you see that ID_KEY_ID go get him.") the value can change with each authentication by hashing with some exchange specific information like the nonces: ID_KEY_ID[x+1] = hash(ID_KEY_ID[x] | Ni | Nr) where ID_KEY_ID[0] = the initial seeded value Once you sucessfully authenticate using ID_KEY_ID[x] update the pre-shared key database so the existing pre-shared key (and hidden "real" identity) will not be associated with ID_KEY_ID[x+1]. Dan. On Tue, 07 Dec 1999 12:43:03 PST you wrote > I propose below a very simple fix for the following problem, which has > been pointed out by many people: in main mode with preshared keys, the > responder cannot decrypt IDii, the initiator's identity payload, unless > the responder knows the preshared key, which in turn depends on the > initiator's identity. > > Two workarounds have been proposed: > > (1) The use of the source-IP-address field in IP packets as identity, > rather than the ID payload, at least in this case. > > (2) The introduction of a completely new mode with different security > properties ("IKE Base Mode", Internet draft by Yael Dayan and Sara > Bitan). > > In my opinion, (1) is a bad idea for the following reasons: > > - It goes against the spirit of the ISAKMP and IPSEC protocols. For > example, ISAKMP has an Identity Protection exchange, of which Main Mode > is an instance. This exchange protects the identities of the parties > carried in the ID payload. Ignoring the ID payload and using instead the > source IP address in the packets defeats the nominal purpose (identity > protection) of the exchange. As another example, RFC 2407 (DOI), > Section 4.6.2, says "The Identification Payload is used to identify the > initator of the Security Association. The identity of the initiator > SHOULD be used by the responder to determine the correct host system > security policy requirement for the association." > > - It introduces ambiguities and creates confusion. (When should the ID > payload be used for identification? When should the source IP address > be used instead? Should both be used for different identification > purposes? If both are different, should identification fail? If a > certificate is used, should it certify the ID payload, or the source IP > address, or both? Solving all these questions could take years...) > > - It introduces a special case, which reduces the quality of the > protocol, and increases its complexity. > > - It doesn't work in cases where IP addresses are assigned dynamically, > such as remote access. > > The proposed IKE Base Mode would be a useful addition to IKE because it > is based on the ISAKMP Base Exchange, which provides a different set of > security tradeoffs than those available in the Identity Protection > Exchange (Main Mode) and the Aggressive Exchange (Aggressive Mode). > Specifically, it provides some protection against DoS and allows for > negotiation of the DH group, while sacrificing identity protection. > > However Base Mode does not solve the problem. It remains impossible to > provide identity protection (the nominal goal of the Identity Protection > exchange used by Main Mode) while using preshared keys. > > The problem comes from the fact that keying material (SKEYID_d, SKEYID_a > and SKEYID_e) is derived from two different sources: the Diffie-Hellman > secret g^xy, and the secret used for authentication. This is so in the > case of authentication by preshared key, as well as in the case of > authentication by public key encryption. > > But there is no reason why the keying material should be derived from > these two sources. In other protocols that use ephemeral > Diffie-Hellman, the keying material is derived only from the > Diffie-Hellman secret. > > So I'd like to propose that we derive the keying material exclusively > from the Diffie-Hellman secret. One way of doing this with minimal > change to the existing protocol is simply to change > > SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) > SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) > SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) > > to > > SKEYID_d = hash(g^xy | CKY-I | CKY-R | 0) > SKEYID_a = hash(SKEYID_d | g^xy | CKY-I | CKY-R | 1) > SKEYID_e = hash(SKEYID_a | g^xy | CKY-I | CKY-R | 2) > > I believe this solves the problem. > > Note that there is a related problem mentioned in RFC 2409, Section 5.4: > > When using pre-shared key authentication with Main Mode the key can > only be identified by the IP address of the peers since HASH_I must > be computed before the initiator has processed IDir. > > However this is not a real problem for the following reasons. > > First, the initiator should know who it wants to communicate with, and > therefore should be able to determine the preshared key. Granted, the > *IKE code* may not know, but this is a software architecture issue > rather than a protocol problem. > > Secondly, the responder does not have this problem (assuming that the > above fix has been applied, and the responder can decrypt IDii). > > The remote access problem is then solved as follows: > > - The remote client initiates contact with the security gateway at a > known, fixed IP address. IKE on the remote client can find the > preshared key based on this address, or else the remote access code can > obtain the preshared key from the user and pass it to IKE. IKE uses it > to compute HASH_I before sending the 5th message in the Main Mode > exchange. > > - The remote client has a dynamically assigned IP address, but it > identifies itself using, for example, a fully-qualified username > (ID_USER_FQDN in the DOI) in the IDii payload. After the gateway > receives and decrypts the payload, it looks up the corresponding > preshared key and uses it compute HASH_R before sending the 6th message > of the exchange. > > Francisco Corella > > (francisco_corella@hp.com) > From owner-ipsec@lists.tislabs.com Tue Dec 7 15:53:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07925; Tue, 7 Dec 1999 15:53:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02313 Tue, 7 Dec 1999 17:40:53 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002242DC9@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Jan Vilhuber'" Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Tue, 7 Dec 1999 14:43:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why does it require a new DOI? Why can't we just define a new "heartbeat" application using, e.g., UDP port X? By definition the phase 2 SA in this scenario is end-to-end, and so to agree on its parameters within IKE we need to specify the protocol (and perhaps port number) used in the service. Why does this have to be any different than restricting end-to-end traffic on the SA to TCP port 23? -- Jesse -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Tuesday, December 07, 1999 1:14 PM To: Ricky Charlet Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) On Tue, 7 Dec 1999, Ricky Charlet wrote: > > > I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or > > 'hijacked' tunnelled ESP. I think this is a new protocol but I don't think > > it justifies an SA of its own. I think using an ISAKMP notification is best > > as most people seem to want this associated with the phase 1 SA. > > > > I'd like to see dead peer detection be in a dedicated IPsec SA pair per > peer pair. There are several good things about doing dead peer detection > this way: > This would require a new DOI, no? It's a dedicated phase 2 SA, but it's not (I claim) an ipsec SA. So a new DOI is needed. jan > * If there are multiple IKE or IPsec SAs to same peer, only need one > 'keepalive' session. > > * Allows IKE SAs to go away (or dangle the IPsec SAs) if an > implementation so wishes. > > * Does not interfere with packet counts or inactivity time outs of IKE > or other IPsec SAs. > > * IPsec may architecturally swap key management protocol without > worrying about loosing dead peer detection functions. > > * may be enabled or disabled per peer by policy > > > > Here is one negative that I can think of: If one peer reconfigures such > that some but not all current IPsec SAs become defunct, this scheme may > not detect that or may think all current SAs became defunct. This could > be engineered around with a dead peer recovery detection algorithm. > > -- > #################################### > # Ricky Charlet > # (510) 795-6903 > # rcharlet@redcreek.com > #################################### > > end Howdy; > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Dec 7 16:11:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08223; Tue, 7 Dec 1999 16:11:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02406 Tue, 7 Dec 1999 17:59:14 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 7 Dec 1999 15:02:14 -0800 (PST) From: Jan Vilhuber To: "Walker, Jesse" cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B002242DC9@hdsmsx31.hd.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We're seeing two different philosophies here, I think. Send the keepalive/heartbeat via phase 1, or send it via phase 2's. Phase 1 makes intuitive sense to me, if you include SPI information in the keepalive, as I proposed previously. This comes at the cost of possibly having to renegotiate the phase 1 SA more often than for rekeying, but is NOT the same as continuous channel mode (which a lot of people are assuming). If you send it via phase 2, you either need a separate SA for this, i.e. ONLY for keepalives, or you send it via some existing ipsec SA. For the record, I like neither of the phase 2 approaches (as if that wasn't obvious). IPSEC SA's are for ipsec traffic, not for maintenance traffic, meaning they are for bulk traffic. Do you really want to have to examine every packet running through your SA (in the second case) as to whether this is real ipsec traffic or maintenance traffic? You pay a performance penalty for this, which I personally feel is not justified. In the other case, where you have a special SA, you have to somehow identify it as being special. I'd rather leave ipsec SA's carrying ipsec traffic, and not make a 'special' SA, which looks like an ipsec SA, but isn't. Whether or not a new DOI is the way to go or not, I'm not sure, but I don't think we should abuse ipsec SA's for maintenance traffic. It needlessly complicates it, which is counter to what many people believe about security protocols: Simple is good; Complex is insecure. I like the fact that we can just let the phase 1 die silently, without having to keep it around for keepalives, and for this you'd need another phase 2 SA. I'd just prefer to not call it a 'special ipsec SA'. That clutters up a lot of things. Maybe there's better way to unambiguously distinguish this from a ipsec Sa, other than via a new DOI. But I don't think it's just the traffic that needs to be 'special' but the SA as well. Otherwise you'll have to clutter up too much ipsec code (I think. I could be wrong). Is that an accurate summary (with commentary)? jan On Tue, 7 Dec 1999, Walker, Jesse wrote: > Why does it require a new DOI? Why can't we just define a new "heartbeat" > application using, e.g., UDP port X? By definition the phase 2 SA in this > scenario is end-to-end, and so to agree on its parameters within IKE we need > to specify the protocol (and perhaps port number) used in the service. Why > does this have to be any different than restricting end-to-end traffic on > the SA to TCP port 23? > > -- Jesse > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Tuesday, December 07, 1999 1:14 PM > To: Ricky Charlet > Cc: ipsec@lists.tislabs.com > Subject: Re: Heartbeats (was RE: keepalives) > > > On Tue, 7 Dec 1999, Ricky Charlet wrote: > > > > > I'm not sure what heartbeat packet is best, ISAKMP, transport ESP or > > > 'hijacked' tunnelled ESP. I think this is a new protocol but I don't > think > > > it justifies an SA of its own. I think using an ISAKMP notification is > best > > > as most people seem to want this associated with the phase 1 SA. > > > > > > > > I'd like to see dead peer detection be in a dedicated IPsec SA pair > per > > peer pair. There are several good things about doing dead peer detection > > this way: > > > This would require a new DOI, no? It's a dedicated phase 2 SA, but it's not > (I claim) an ipsec SA. So a new DOI is needed. > > jan > > > > > * If there are multiple IKE or IPsec SAs to same peer, only need one > > 'keepalive' session. > > > > * Allows IKE SAs to go away (or dangle the IPsec SAs) if an > > implementation so wishes. > > > > * Does not interfere with packet counts or inactivity time outs of IKE > > or other IPsec SAs. > > > > * IPsec may architecturally swap key management protocol without > > worrying about loosing dead peer detection functions. > > > > * may be enabled or disabled per peer by policy > > > > > > > > Here is one negative that I can think of: If one peer reconfigures > such > > that some but not all current IPsec SAs become defunct, this scheme may > > not detect that or may think all current SAs became defunct. This could > > be engineered around with a dead peer recovery detection algorithm. > > > > -- > > #################################### > > # Ricky Charlet > > # (510) 795-6903 > > # rcharlet@redcreek.com > > #################################### > > > > end Howdy; > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Dec 7 16:19:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08420; Tue, 7 Dec 1999 16:18:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02424 Tue, 7 Dec 1999 18:02:04 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD1C0@exchange> From: Andrew Krywaniuk To: Dan Harkins , francisco_corella@hp.com Cc: ipsec@lists.tislabs.com Subject: RE: A fix for main mode with preshared keys Date: Tue, 7 Dec 1999 18:07:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For those of you who are concerned about massive evesdropping on the > Internet and tracking of opaque blobs ("dfnmtynioghora was in Grozny > on Tuesday and Khartoum on Thursday, it _must_ Osama Bin > Laden! Next time > you see that ID_KEY_ID go get him.") the value can change with each > authentication by hashing with some exchange specific > information like > the nonces: > > ID_KEY_ID[x+1] = hash(ID_KEY_ID[x] | Ni | Nr) > where ID_KEY_ID[0] = the initial seeded value > > Once you sucessfully authenticate using ID_KEY_ID[x] update > the pre-shared > key database so the existing pre-shared key (and hidden > "real" identity) > will not be associated with ID_KEY_ID[x+1]. So what you are suggesting is essentially a second pre-shared key (the iv for the ID_KEY_ID). And this must always be synchronized between the peers, so if one peer crashes and has to restore his HD from backups or if the negotiation is aborted between the transmission and reception of packets N and N+1 (for some N), then they must manually resynchronize. I thought IKE was a stateless protocol. :-) Is it really that hard to not make SKEYID_e dependent on the shared secret? It can still be used to derive SKEYID_d. I know you said you were concerned about changing the keymat generation technique for an established protocol, but isn't it the general derivation technique that requires analysis and not the specific definition of SKEYID_e as prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2). Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Dec 7 16:32:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08699; Tue, 7 Dec 1999 16:32:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02522 Tue, 7 Dec 1999 18:20:00 -0500 (EST) Date: Wed, 8 Dec 1999 08:23:24 +0900 (JST) From: Shoichi Sakane Message-Id: <199912072323.IAA17886@ghost.wide.ydc.co.jp> To: tjenkins@TimeStep.com Cc: msa@hemuli.tte.vtt.fi, ipsec@lists.tislabs.com Subject: RE: interpretation of SA bundle. In-Reply-To: Your message of "Tue, 7 Dec 1999 08:44:36 -0500 " <319A1C5F94C8D11192DE00805FBBADDFFFCE74@exchange> References: <319A1C5F94C8D11192DE00805FBBADDFFFCE74@exchange> X-Mailer: Cue version 0.6 (991206-0337/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Node A sends a proposal including AH tunnel mode followed by ESP > > tunnel > > > mode. In this case, we should interpreted to be created IP > > payload by > > > using this SA, > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > > 2. [outer IP][ESP][AH][inner IP][ULP] > > > 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP] > > > 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP] > > Assuming the proposal order as you stated: 4 (e.g. first apply > > tunnel+AH, then tunnel+ESP). Note, in (1) AH and in (2) ESP is > > transport mode, so they don't match your proposal anyway. My interpretation is #3. I think the order of proposal and transform means the order of security protocal header in IP packet. > > The result should depend on the ordering in the proposal? I don't know > > about IKE, but I can express all of the above combinations in my > > policy file, and the kernel IPSEC machinery can do them. I can do that. On IKE negotiation, it is only thing that the order of proposal express local policy file that you say. So I clarify the interpretation of the order. > First, let's be explicit about how this was proposed. If this was > proposed as a single SA payload with multiple proposal payloads > with the same number, then: I assumed what you say. Additionally, there are encapsulation mode in each attributes. That is like below: SA payload Proposal: #1 AH Transform: #1 HMAC-SHA Attributes: Tunnel Proposal: #1 ESP Transform: #1 ES_3DES Attributes: Tunnel > We discussed this and tested this at a bake-offs quite some time ago and > the concensus seemed to be that the order of application was not as > proposed, but as to what made sense. That order was (outbound processing) > IPCOMP before ESP before AH, no matter what the order of proposal. > Secondly, the attributes across the proposals are to be consistent, > and that they must apply to the bundle as a whole. [Aside: this is > specifically called an SA suite in the MIBs.] This means that a > bundle (of this type) is all transport mode or all tunnel mode. Do you say that each attributes of multiple proposal with same number MUST have same transport mode ? > This means that the correct answer for the above questions is 1. #1 is first applyed ESP tunnel, then second AH transport. Am I missing ? > > > Another case, Node A sends a proposal including AH transport mode > > followed > > > by ESP tunnel mode. > > > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > > 2. [outer IP][ESP][inner IP][AH][ULP] > > > > > > I think there is not these rules of interpretation in any drafts. > > > > The case 2 (e.g. first apply AH, then tunnel+ESP). I guess the rule > > should just state: apply strictly in proposed order. > Again, with the same assumptions, the second case is inconsistent. > However, our implementation will convert the transport mode to > tunnel, and apply tunnel to the whole thing. Therefore, the answer > is 1. Regarding to what you say, the correct answer is not to be accepted the proposal of mixed both transport and tunnel mode ? > I third the suggestion that this needs to be clearer. Our implementation > originally did what Markku's did. It no longer does. Our kernel can do any combination and many nesting, but I don't know the currect way to express these combination and nesting on IKE. Regards, /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Tue Dec 7 17:37:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09828; Tue, 7 Dec 1999 17:37:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02723 Tue, 7 Dec 1999 19:16:00 -0500 (EST) Message-Id: <199912080019.TAA11149@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Tue, 07 Dec 1999 14:43:54 PST." <392A357CE6FFD111AC3E00A0C99848B002242DC9@hdsmsx31.hd.intel.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 Dec 1999 19:19:32 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Walker," == Walker, Jesse writes: Walker,> Why does it require a new DOI? Why can't we just define a new Walker,> "heartbeat" application using, e.g., UDP port X? By definition Actually, we don't even need to do that. You can use ICMP ping, or the UDP echo service. Walker,> (and perhaps port number) used in the service. Why does this Walker,> have to be any different than restricting end-to-end traffic on Walker,> the SA to TCP port 23? I think that some gateways have not implemented all of these features, but I think that's their problem. I would still like to see an "IKE ping" facility added that is valid even without a phase 1 SA for debugging purposes. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Tue Dec 7 18:21:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14799; Tue, 7 Dec 1999 18:21:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02905 Tue, 7 Dec 1999 20:00:38 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 7 Dec 1999 17:03:28 -0800 (PST) From: Jan Vilhuber To: "Michael C. Richardson" cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: <199912080019.TAA11149@istari.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Dec 1999, Michael C. Richardson wrote: > > >>>>> "Walker," == Walker, Jesse writes: > Walker,> Why does it require a new DOI? Why can't we just define a new > Walker,> "heartbeat" application using, e.g., UDP port X? By definition > > Actually, we don't even need to do that. You can use ICMP ping, or > the UDP echo service. > And how would you know if this is a 'heartbeat' or whether the user of the tunnel is pinging (icmp or udp echo, whatever), i.e. how do you distinguish this from real traffic? Why is that important? People want to account for things. They want to charge for things. If you skew the counts with bogus 'real traffic' (or don't count real traffic because you mistake it for bogus keepalive traffic), then your counts will be off. You really have to have a quick and easy and uncomplicated way of determining if this is real traffic or not. The best way is to keep it completely separate from ipsec traffic, which means don't use any existing ipsec tunnels for this, and also don't use any spoofed/special ipsec SA's for this. A totally different phase 2 SA is needed (does this translate into a new DOI? And would that really help? Beats me), or you use phase 1. jan > Walker,> (and perhaps port number) used in the service. Why does this > Walker,> have to be any different than restricting end-to-end traffic on > Walker,> the SA to TCP port 23? > > I think that some gateways have not implemented all of these features, but > I think that's their problem. > I would still like to see an "IKE ping" facility added that is valid even > without a phase 1 SA for debugging purposes. > > :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? > Michael Richardson | Cow#2: No. I'm a duck. > Home: mcr@sandelman.ottawa.on.ca. PGP key available. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Dec 7 19:42:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25770; Tue, 7 Dec 1999 19:42:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03196 Tue, 7 Dec 1999 21:27:26 -0500 (EST) Message-Id: <199912080230.VAA13424@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Tue, 07 Dec 1999 17:03:28 PST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 Dec 1999 21:30:57 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jan" == Jan Vilhuber writes: Jan> On Tue, 7 Dec 1999, Michael C. Richardson wrote: >> >>>>> "Walker," == Walker, Jesse writes: >> Walker,> Why does it require a new DOI? Why can't we just define a new >> Walker,> "heartbeat" application using, e.g., UDP port X? By >> definition >> >> Actually, we don't even need to do that. You can use ICMP ping, or the >> UDP echo service. Jan> And how would you know if this is a 'heartbeat' or whether the user Jan> of the tunnel is pinging (icmp or udp echo, whatever), i.e. how do Jan> you distinguish this from real traffic? a) the user doesn't ping the internal interface of the gateway. b) who cares. If the user is alive, the user is alive. Jan> Why is that important? People want to account for things. They want Jan> to charge for things. If you skew the counts with bogus 'real Jan> traffic' (or don't count real traffic because you mistake it for Jan> bogus keepalive traffic), then your counts will be off. By 64 bytes per minute? Come on. TCP retransmits take more overhead than that. c) you make the heartbeat channel a seperate SA, as you suggested. You just don't need the new "service" Jan> existing ipsec tunnels for this, and also don't use any Jan> spoofed/special ipsec SA's for this. A totally different phase 2 SA Jan> is needed (does this translate into a new DOI? And would that Jan> really help? Beats me), or you use phase 1. 1. the phase 1 may be dropped. You user might want to do this as well as the gateway, as they may have limited ram (think PalmPilot). So the existence (or lack of) of an active IKE daemon doesn't mean that the user has gone. 2. who cares if the phase 1 SA is there. It is the phase 2 SA that you want to clean up. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Tue Dec 7 20:08:45 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA29583; Tue, 7 Dec 1999 20:08:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03288 Tue, 7 Dec 1999 22:01:19 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 7 Dec 1999 19:04:30 -0800 (PST) From: Jan Vilhuber To: "Michael C. Richardson" cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: <199912080230.VAA13424@istari.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Dec 1999, Michael C. Richardson wrote: > > >>>>> "Jan" == Jan Vilhuber writes: > Jan> On Tue, 7 Dec 1999, Michael C. Richardson wrote: > >> >>>>> "Walker," == Walker, Jesse writes: > >> Walker,> Why does it require a new DOI? Why can't we just define a new > >> Walker,> "heartbeat" application using, e.g., UDP port X? By > >> definition > >> > >> Actually, we don't even need to do that. You can use ICMP ping, or the > >> UDP echo service. > > Jan> And how would you know if this is a 'heartbeat' or whether the user > Jan> of the tunnel is pinging (icmp or udp echo, whatever), i.e. how do > Jan> you distinguish this from real traffic? > > a) the user doesn't ping the internal interface of the gateway. > b) who cares. If the user is alive, the user is alive. > > Jan> Why is that important? People want to account for things. They want > Jan> to charge for things. If you skew the counts with bogus 'real > Jan> traffic' (or don't count real traffic because you mistake it for > Jan> bogus keepalive traffic), then your counts will be off. > > By 64 bytes per minute? Come on. You'd be surprised how picky some customers are... I could tell you stories from PPP accounting that would make you puke... jan > TCP retransmits take more overhead than that. > > c) you make the heartbeat channel a seperate SA, as you suggested. You > just don't need the new "service" > > Jan> existing ipsec tunnels for this, and also don't use any > Jan> spoofed/special ipsec SA's for this. A totally different phase 2 SA > Jan> is needed (does this translate into a new DOI? And would that > Jan> really help? Beats me), or you use phase 1. > > 1. the phase 1 may be dropped. You user might want to do this as well > as the gateway, as they may have limited ram (think PalmPilot). So > the existence (or lack of) of an active IKE daemon doesn't mean > that the user has gone. > > 2. who cares if the phase 1 SA is there. It is the phase 2 SA that you > want to clean up. > > :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? > Michael Richardson | Cow#2: No. I'm a duck. > Home: mcr@sandelman.ottawa.on.ca. PGP key available. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Dec 7 20:09:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA29601; Tue, 7 Dec 1999 20:09:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03261 Tue, 7 Dec 1999 21:52:49 -0500 (EST) Date: Wed, 8 Dec 1999 10:56:02 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: A fix for main mode with preshared keys In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFFFD1C0@exchange> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An additional payload HASH(1) = hash(IDii | Ni) could be sent in Step 3 of Main Mode with pre-shared key to support remore access as well as identity protection. The responder can use HASH(1) to select pre-shared key. Of course, this may affect the protocol performance since the responder need to re-compute HASH(1) from its (ID, pre-shared key) database to find the matched entry. But the performance bottleneck of a VPN is at IPsec rather than at IKE. Jianying On Tue, 7 Dec 1999, Andrew Krywaniuk wrote: > > For those of you who are concerned about massive evesdropping on the > > Internet and tracking of opaque blobs ("dfnmtynioghora was in Grozny > > on Tuesday and Khartoum on Thursday, it _must_ Osama Bin > > Laden! Next time > > you see that ID_KEY_ID go get him.") the value can change with each > > authentication by hashing with some exchange specific > > information like > > the nonces: > > > > ID_KEY_ID[x+1] = hash(ID_KEY_ID[x] | Ni | Nr) > > where ID_KEY_ID[0] = the initial seeded value > > > > Once you sucessfully authenticate using ID_KEY_ID[x] update > > the pre-shared > > key database so the existing pre-shared key (and hidden > > "real" identity) > > will not be associated with ID_KEY_ID[x+1]. > > So what you are suggesting is essentially a second pre-shared key (the iv > for the ID_KEY_ID). And this must always be synchronized between the peers, > so if one peer crashes and has to restore his HD from backups or if the > negotiation is aborted between the transmission and reception of packets N > and N+1 (for some N), then they must manually resynchronize. > > I thought IKE was a stateless protocol. :-) > > Is it really that hard to not make SKEYID_e dependent on the shared secret? > It can still be used to derive SKEYID_d. I know you said you were concerned > about changing the keymat generation technique for an established protocol, > but isn't it the general derivation technique that requires analysis and not > the specific definition of SKEYID_e as prf(SKEYID, SKEYID_a | g^xy | CKY-I | > CKY-R | 2). > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > From owner-ipsec@lists.tislabs.com Tue Dec 7 20:26:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01348; Tue, 7 Dec 1999 20:26:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03358 Tue, 7 Dec 1999 22:13:52 -0500 (EST) Message-ID: <384DCCDE.2D927F21@ire-ma.com> Date: Tue, 07 Dec 1999 22:13:35 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912080230.VAA13424@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a thought - if we have IKE-to-IKE IPSec ESP heartbeat channel (probably with transport encapsulation) using port 500 - we would need somehow to figure out how to distinguish it from IKE port 500 negotiation traffic which is not subjected to IPSec. "Michael C. Richardson" wrote: > >>>>> "Jan" == Jan Vilhuber writes: > Jan> On Tue, 7 Dec 1999, Michael C. Richardson wrote: > >> >>>>> "Walker," == Walker, Jesse writes: > >> Walker,> Why does it require a new DOI? Why can't we just define a new > >> Walker,> "heartbeat" application using, e.g., UDP port X? By > >> definition > >> > >> Actually, we don't even need to do that. You can use ICMP ping, or the > >> UDP echo service. > > Jan> And how would you know if this is a 'heartbeat' or whether the user > Jan> of the tunnel is pinging (icmp or udp echo, whatever), i.e. how do > Jan> you distinguish this from real traffic? > > a) the user doesn't ping the internal interface of the gateway. > b) who cares. If the user is alive, the user is alive. > > Jan> Why is that important? People want to account for things. They want > Jan> to charge for things. If you skew the counts with bogus 'real > Jan> traffic' (or don't count real traffic because you mistake it for > Jan> bogus keepalive traffic), then your counts will be off. > > By 64 bytes per minute? Come on. > TCP retransmits take more overhead than that. > > c) you make the heartbeat channel a seperate SA, as you suggested. You > just don't need the new "service" > > Jan> existing ipsec tunnels for this, and also don't use any > Jan> spoofed/special ipsec SA's for this. A totally different phase 2 SA > Jan> is needed (does this translate into a new DOI? And would that > Jan> really help? Beats me), or you use phase 1. > > 1. the phase 1 may be dropped. You user might want to do this as well > as the gateway, as they may have limited ram (think PalmPilot). So > the existence (or lack of) of an active IKE daemon doesn't mean > that the user has gone. > > 2. who cares if the phase 1 SA is there. It is the phase 2 SA that you > want to clean up. > > :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? > Michael Richardson | Cow#2: No. I'm a duck. > Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Tue Dec 7 20:40:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA03779; Tue, 7 Dec 1999 20:40:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03416 Tue, 7 Dec 1999 22:27:58 -0500 (EST) Message-ID: <384DCFFA.74C259D9@ire-ma.com> Date: Tue, 07 Dec 1999 22:26:51 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: cookie verification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC 2408 in Section 2.5.3 contains few MUSTs as well as recommendations for cookie generation. I am not clear on the "verification of cookie" part, which is the whole reason for not simply selecting a random number for cookies value. Could someone explain the "standard" technique of generation and especially subsequent verification of cookies? Does anyone uses this technique and verifies other vendor cookies? From owner-ipsec@lists.tislabs.com Wed Dec 8 04:26:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23955; Wed, 8 Dec 1999 04:26:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04364 Wed, 8 Dec 1999 06:12:13 -0500 (EST) Message-ID: <010f01bf416c$dcd08630$3e4fa8c0@iaf.fi> From: "Sami Vaarala" To: Cc: "Bronislav Kavsan" References: <384DCFFA.74C259D9@ire-ma.com> Subject: Re: cookie verification Date: Wed, 8 Dec 1999 13:10:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bronislav Kavsan wrote: > RFC 2408 in Section 2.5.3 contains few MUSTs as well as recommendations > for cookie generation. I am not clear on the "verification of cookie" > part, which is the whole reason for not simply selecting a random number > for cookies value. > > Could someone explain the "standard" technique of generation and > especially subsequent verification of cookies? Does anyone uses this > technique and verifies other vendor cookies? Yes, RFC 2408 is extremely vague about the purpose, creation, and verification of cookies. (It is also vague about a lot of other things, but let's not get into that now ;-). For exchanges without an initial stateless phase (ie all the IKE exchanges), the cookie creation method makes no difference, as long as the cookie generation mechanism is *unpredictable* to an outsider (to serve the weak source IP authentication function). Cookie verification then equals comparison to a cookie value stored in some sort of exchange state. Creating cookies using a hash with public and private data (as suggested by RFC 2408) is good since you do not have to waste random numbers for each cookie (indeed, random numbers are a scarce resource :). Otherwise, use your favorite pseudo-random number generator. However, cookies CAN be made more intelligent, see the Photuris RFC (RFC 2522) for an example of how cookies can be used for a stateless beginning in an exchange. A responder will not have to store any state until the source IP of the initiator has been weakly authenticated. ISAKMP *could* take use of such stateless exchanges; none of the IKE exchanges is "stateless", though, and the stateless nature of cookies is academic for IKE. (In IKE you need to store data from the first initiator message in order to participate in the exchange later). It is possible to write a cookie generation function that allows us to: (1) verify that a cookie was created by us (2) determine the approximate age of the cookie (eg with a 1 second resolution up to 15 minutes) (3) determine the role for which the cookie was created (initiator vs. responder, main mode vs. aggressive mode, source and dest IP address/ports, etc) without storing any cookie-per-cookie state, and by using one hash and one DES operation per cookie verification and creation. This extra information can be used to eg defend against replay/reflection attacks in a exchange-neutral manner (ie the message is dropped even before IKE exchange code is invoked). Having said that, it does not PREVENT such attacks indefinitely. It only serves as extra protection for some period of time after completion of an exchange (and can trivially block interleaved reflections). It would be good to include a better discussion of the cookie security function in a future ISAKMP specification. I would also like to see pseudo-code for a basic implementation, and an example of a stateless application. Sami -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Wed Dec 8 04:51:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24266; Wed, 8 Dec 1999 04:51:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04496 Wed, 8 Dec 1999 06:49:10 -0500 (EST) Message-ID: <384E4577.5D27E67E@ire-ma.com> Date: Wed, 08 Dec 1999 06:48:09 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sami Vaarala CC: ipsec@lists.tislabs.com Subject: Re: cookie verification References: <384DCFFA.74C259D9@ire-ma.com> <010f01bf416c$dcd08630$3e4fa8c0@iaf.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sami - excellent overview! That's exactly what I was looking for, thank you very much! In summary - because in the current IKE the cookies are not fully "baked" yet :) - any random or pseudo-random values will work just fine - and with some future standardization in this area - the value of intelligent cookies in IKE can be enhanced. Until this is the case - all RFC2408 MUSTs about cookie generation should be interpreted as MAY, right? Sami Vaarala wrote: > Bronislav Kavsan wrote: > > RFC 2408 in Section 2.5.3 contains few MUSTs as well as recommendations > > for cookie generation. I am not clear on the "verification of cookie" > > part, which is the whole reason for not simply selecting a random number > > for cookies value. > > > > Could someone explain the "standard" technique of generation and > > especially subsequent verification of cookies? Does anyone uses this > > technique and verifies other vendor cookies? > > Yes, RFC 2408 is extremely vague about the purpose, creation, and > verification > of cookies. (It is also vague about a lot of other things, but let's not > get > into that now ;-). > > For exchanges without an initial stateless phase (ie all the IKE exchanges), > the cookie creation method makes no difference, as long as the cookie > generation > mechanism is *unpredictable* to an outsider (to serve the weak source IP > authentication function). Cookie verification then equals comparison to a > cookie > value stored in some sort of exchange state. > > Creating cookies using a hash with public and private data (as suggested by > RFC 2408) > is good since you do not have to waste random numbers for each cookie > (indeed, > random numbers are a scarce resource :). Otherwise, use your favorite > pseudo-random > number generator. > > However, cookies CAN be made more intelligent, see the Photuris RFC (RFC > 2522) > for an example of how cookies can be used for a stateless beginning in an > exchange. A responder will not have to store any state until the source IP > of the initiator has been weakly authenticated. > > ISAKMP *could* take use of such stateless exchanges; none of the IKE > exchanges is "stateless", though, and the stateless nature of cookies is > academic for IKE. > (In IKE you need to store data from the first initiator message in order to > participate in the exchange later). > > It is possible to write a cookie generation function that allows us to: > (1) verify that a cookie was created by us > (2) determine the approximate age of the cookie (eg with a 1 second > resolution > up to 15 minutes) > (3) determine the role for which the cookie was created (initiator vs. > responder, > main mode vs. aggressive mode, source and dest IP address/ports, etc) > without storing any cookie-per-cookie state, and by using one hash and one > DES > operation per cookie verification and creation. > > This extra information can be used to eg defend against replay/reflection > attacks > in a exchange-neutral manner (ie the message is dropped even before IKE > exchange > code is invoked). Having said that, it does not PREVENT such attacks > indefinitely. > It only serves as extra protection for some period of time after completion > of an > exchange (and can trivially block interleaved reflections). > > It would be good to include a better discussion of the cookie security > function > in a future ISAKMP specification. I would also like to see pseudo-code for > a > basic implementation, and an example of a stateless application. > > Sami > > -- > Sami Vaarala (sami.vaarala@netseal.com) > NetSeal Technologies > http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Wed Dec 8 05:40:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA24778; Wed, 8 Dec 1999 05:40:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04715 Wed, 8 Dec 1999 07:30:53 -0500 (EST) Message-ID: <013401bf4177$dae779e0$3e4fa8c0@iaf.fi> From: "Sami Vaarala" To: "Bronislav Kavsan" Cc: References: <384DCFFA.74C259D9@ire-ma.com> <010f01bf416c$dcd08630$3e4fa8c0@iaf.fi> <384E4577.5D27E67E@ire-ma.com> Subject: Re: cookie verification Date: Wed, 8 Dec 1999 14:29:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bronislav, > Sami - excellent overview! That's exactly what I was looking for, > thank you very much! > In summary - because in the current IKE the cookies are not fully "baked" yet :) > - any random or pseudo-random values will work just fine - and with some future > standardization in this area - the value of intelligent cookies in IKE can be > enhanced. I must add a disclaimer to my post -- it was intended to convey my personal interpretation of the specifications. It would be nice if someone with more authority on the subject would give a clean description of cookies and whether my analysis is correct :) It would be interesting to know if there is anything real to be gained by using more "intelligent" cookies, like the ones I described in the post (they are actually used by our implementation). > Until this is the case - all RFC2408 MUSTs about cookie generation should be > interpreted as MAY, right? In my interpretation, yes. The cookie requirements in ISAKMP were lifted almost word-for-word from Photuris, which uses the cookies usefully to prevent state creation in denial-of-service attacks. I must stress that as far as I understand, ISAKMP *could* use a similar mechanism (indeed, there is a note of a "header exchange" which is not elaborated further), although IKE does not (currently) take advantage of it. As far as I see it, the only real requirement for IKE is that the cookies must be unpredictable to an outsider; the method of creating them by hashing "stuff" (including IP addresses) fulfills that goal. Sami -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Wed Dec 8 06:59:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25863; Wed, 8 Dec 1999 06:59:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04912 Wed, 8 Dec 1999 08:38:10 -0500 (EST) Date: Wed, 8 Dec 1999 15:41:37 +0200 (EET) From: Markku Savela Message-Id: <199912081341.PAA22168@anise.tte.vtt.fi> To: niklas@appli.se CC: sakane@ydc.co.jp, tjenkins@TimeStep.com, ipsec@lists.tislabs.com In-reply-to: <199912080048.BAA07242@waldorf.appli.se> (message from Niklas Hallqvist on Wed, 08 Dec 1999 01:48:52 +0100) Subject: Re: interpretation of SA bundle. Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > As I think Tim pointed out, the list had a rough consensus that only > sane (useful) ordering should be applied to the packets, no matter > what ordering the protocols have in the IKE SA payload. The reason > being that limiting flexibility and thus complexity of IKE will > improve interoperability. First, IKE should not be making decisions about what is sane and what is not. If a user wants to use "insane" ordering, systems at *this* level should allow it. The "sane" vs. "insane" choices should be left up to the higher level tools, such as policy editors and configuration tools. Second, all these ad hoc rules about what is sane or not are not making implmentations simple, quite contrary. If we want SIMPLE, IKE should just negotiate single unidirectional SA on responce to a ACQUIRE message (or equivalent). No bundles, no worries about ordering or about multiple transport/tunnel modes, everything goes. All that is negotiated are the SA parameters: lifetimes, algorithms and keys to be used. Of course this is my old fight, which I cannot win: No bundles on IKE level, bundles are policy concept which IKE really does not need to know about. However, to be at least minimally compatible with others, I may thrive for an IKE implementation that negotiates the SA's of the first offered bundle, for which all algorithm support exists, but ignoring the ordering. If order on the policy of the other end does not match the user defined local policy, then packets are dropped even though negotiation succeeds... -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ ps. While testing with KAKE, I seemed notice that it is not too picky about ordering of SA's in bundle (I had some weird combo of few AHs and ESP's with tunnel thrown in, and my end complained about mismatch in policy, but KAME was happy with any order as long as SA's were present, this was with manual keys only and I was applying the same SA's multiple times on same packet (yes insane, but ... :-)). From owner-ipsec@lists.tislabs.com Wed Dec 8 07:26:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26266; Wed, 8 Dec 1999 07:26:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04986 Wed, 8 Dec 1999 09:16:09 -0500 (EST) Message-ID: <384E6868.BC59AFAD@ire-ma.com> Date: Wed, 08 Dec 1999 09:17:12 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912080230.VAA13424@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Doing heartbeats over IKE SA or IPSec SA is not free - i.e. the gateway connected to 1000 Clients needs 1000 addtional heartbeat IPSec SAs to negotiate and maintain - very ugly! I am still not convinced about security implications of unsecure hearbeats - and would be interested in what people think. "Michael C. Richardson" wrote: > >>>>> "Jan" == Jan Vilhuber writes: > Jan> On Tue, 7 Dec 1999, Michael C. Richardson wrote: > >> >>>>> "Walker," == Walker, Jesse writes: > >> Walker,> Why does it require a new DOI? Why can't we just define a new > >> Walker,> "heartbeat" application using, e.g., UDP port X? By > >> definition > >> > >> Actually, we don't even need to do that. You can use ICMP ping, or the > >> UDP echo service. > > Jan> And how would you know if this is a 'heartbeat' or whether the user > Jan> of the tunnel is pinging (icmp or udp echo, whatever), i.e. how do > Jan> you distinguish this from real traffic? > > a) the user doesn't ping the internal interface of the gateway. > b) who cares. If the user is alive, the user is alive. > > Jan> Why is that important? People want to account for things. They want > Jan> to charge for things. If you skew the counts with bogus 'real > Jan> traffic' (or don't count real traffic because you mistake it for > Jan> bogus keepalive traffic), then your counts will be off. > > By 64 bytes per minute? Come on. > TCP retransmits take more overhead than that. > > c) you make the heartbeat channel a seperate SA, as you suggested. You > just don't need the new "service" > > Jan> existing ipsec tunnels for this, and also don't use any > Jan> spoofed/special ipsec SA's for this. A totally different phase 2 SA > Jan> is needed (does this translate into a new DOI? And would that > Jan> really help? Beats me), or you use phase 1. > > 1. the phase 1 may be dropped. You user might want to do this as well > as the gateway, as they may have limited ram (think PalmPilot). So > the existence (or lack of) of an active IKE daemon doesn't mean > that the user has gone. > > 2. who cares if the phase 1 SA is there. It is the phase 2 SA that you > want to clean up. > > :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? > Michael Richardson | Cow#2: No. I'm a duck. > Home: mcr@sandelman.ottawa.on.ca. PGP key available. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Wed Dec 8 07:34:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26498; Wed, 8 Dec 1999 07:34:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04994 Wed, 8 Dec 1999 09:16:36 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD255@exchange> From: Tim Jenkins To: Shoichi Sakane Cc: msa@hemuli.tte.vtt.fi, ipsec@lists.tislabs.com Subject: RE: interpretation of SA bundle. Date: Wed, 8 Dec 1999 09:20:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Shoichi Sakane [mailto:sakane@ydc.co.jp] > Sent: December 7, 1999 6:23 PM > To: tjenkins@TimeStep.com > Cc: msa@hemuli.tte.vtt.fi; ipsec@lists.tislabs.com > Subject: RE: interpretation of SA bundle. > > > > > > Node A sends a proposal including AH tunnel mode followed by ESP > > > tunnel > > > > mode. In this case, we should interpreted to be created IP > > > payload by > > > > using this SA, > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > > > 2. [outer IP][ESP][AH][inner IP][ULP] > > > > 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP] > > > > 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP] > > > Assuming the proposal order as you stated: 4 (e.g. first apply > > > tunnel+AH, then tunnel+ESP). Note, in (1) AH and in (2) ESP is > > > transport mode, so they don't match your proposal anyway. > > My interpretation is #3. I think the order of proposal and transform > means the order of security protocal header in IP packet. Number 3 has inserted an extra IP header. That implies a separation of the SAs. This would have been negotiated by two separate quick modes, one that said that ESP was needed for the ULP, and another that AH is needed for ESP. Think about your SPDs and selectors if you do this, and also the policy relationship. The selectors negotiated refer to the ULP, since they're not part of the SA payload. > > > > The result should depend on the ordering in the proposal? > I don't know > > > about IKE, but I can express all of the above combinations in my > > > policy file, and the kernel IPSEC machinery can do them. > > I can do that. On IKE negotiation, it is only thing that the order of > proposal express local policy file that you say. So I clarify the > interpretation of the order. > > > First, let's be explicit about how this was proposed. If this was > > proposed as a single SA payload with multiple proposal payloads > > with the same number, then: > > I assumed what you say. Additionally, there are encapsulation mode > in each attributes. That is like below: > > SA payload > Proposal: #1 AH > Transform: #1 HMAC-SHA > Attributes: Tunnel > Proposal: #1 ESP > Transform: #1 ES_3DES > Attributes: Tunnel > > > We discussed this and tested this at a bake-offs quite some > time ago and > > the concensus seemed to be that the order of application was not as > > proposed, but as to what made sense. That order was > (outbound processing) > > IPCOMP before ESP before AH, no matter what the order of proposal. > > > Secondly, the attributes across the proposals are to be consistent, > > and that they must apply to the bundle as a whole. [Aside: this is > > specifically called an SA suite in the MIBs.] This means that a > > bundle (of this type) is all transport mode or all tunnel mode. > > Do you say that each attributes of multiple proposal with same number > MUST have same transport mode ? The encapsulation is applied to the SAs as a whole. So, yes. See section 2.1 of RFC 2408. Here's what you're doing when you have multiple proposal payloads with the same number in a single SA payload: ==> Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security protocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole. <== "All of the protections in a suite must be treated as a single unit." In other words, the group of SAs that make up the suite live and die as a unit, and have encapulation applied as a single logical unit. > > > This means that the correct answer for the above questions is 1. > > #1 is first applyed ESP tunnel, then second AH transport. Am > I missing ? That's a potential way to do the implementation in the kernal. I don't dispute it's confusing, but that's what has evolved. > > > > > Another case, Node A sends a proposal including AH > transport mode > > > followed > > > > by ESP tunnel mode. > > > > > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > > > 2. [outer IP][ESP][inner IP][AH][ULP] > > > > > > > > I think there is not these rules of interpretation in > any drafts. > > > > > > The case 2 (e.g. first apply AH, then tunnel+ESP). I > guess the rule > > > should just state: apply strictly in proposed order. > > > Again, with the same assumptions, the second case is inconsistent. > > However, our implementation will convert the transport mode to > > tunnel, and apply tunnel to the whole thing. Therefore, the answer > > is 1. > > Regarding to what you say, the correct answer is not to be accepted > the proposal of mixed both transport and tunnel mode ? What I intended to say was that if the proposals that our implementation receives are mixed, we treat that as a request for tunnel mode. This is our interpretation only. What it means is that there's a chance we'll get it right if the peer proposes how they would implement the encapsulation. What we send is tunnel mode for all, or transport for all, depending on how we want the group as a whole to be applied. > > > I third the suggestion that this needs to be clearer. Our > implementation > > originally did what Markku's did. It no longer does. > > Our kernel can do any combination and many nesting, but I don't know > the currect way to express these combination and nesting on IKE. > > Regards, > > /Shoichi `NE' Sakane @ KAME project/ > From owner-ipsec@lists.tislabs.com Wed Dec 8 08:32:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27789; Wed, 8 Dec 1999 08:32:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05230 Wed, 8 Dec 1999 10:04:23 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Wed, 8 Dec 1999 07:07:48 -0800 Message-Id: In-Reply-To: Subject: RE: A fix for main mode with preshared keys MIME-Version: 1.0 To: jyzhou@krdl.org.sg Cc: akrywaniuk@TimeStep.com, ipsec@lists.tislabs.com Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline; filename="RE:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Do you mean that the responder computes hash(ID,Ni) for *every* entry (ID, pre-shared key) in the database?! That won't scale beyond a few entries... Francisco ______________________________ Reply Separator _________________________________ Subject: RE: A fix for main mode with preshared keys Author: Non-HP-jyzhou (jyzhou@krdl.org.sg) at HP-ColSprings,mimegw5 Date: 12/7/99 6:56 PM An additional payload HASH(1) = hash(IDii | Ni) could be sent in Step 3 of Main Mode with pre-shared key to support remore access as well as identity protection. The responder can use HASH(1) to select pre-shared key. Of course, this may affect the protocol performance since the responder need to re-compute HASH(1) from its (ID, pre-shared key) database to find the matched entry. But the performance bottleneck of a VPN is at IPsec rather than at IKE. Jianying On Tue, 7 Dec 1999, Andrew Krywaniuk wrote: > > For those of you who are concerned about massive evesdropping on the > > Internet and tracking of opaque blobs ("dfnmtynioghora was in Grozny > > on Tuesday and Khartoum on Thursday, it _must_ Osama Bin > > Laden! Next time > > you see that ID_KEY_ID go get him.") the value can change with each > > authentication by hashing with some exchange specific > > information like > > the nonces: > > > > ID_KEY_ID[x+1] = hash(ID_KEY_ID[x] | Ni | Nr) > > where ID_KEY_ID[0] = the initial seeded value > > > > Once you sucessfully authenticate using ID_KEY_ID[x] update > > the pre-shared > > key database so the existing pre-shared key (and hidden > > "real" identity) > > will not be associated with ID_KEY_ID[x+1]. > > So what you are suggesting is essentially a second pre-shared key (the iv > for the ID_KEY_ID). And this must always be synchronized between the peers, > so if one peer crashes and has to restore his HD from backups or if the > negotiation is aborted between the transmission and reception of packets N > and N+1 (for some N), then they must manually resynchronize. > > I thought IKE was a stateless protocol. :-) > > Is it really that hard to not make SKEYID_e dependent on the shared secret? > It can still be used to derive SKEYID_d. I know you said you were concerned > about changing the keymat generation technique for an established protocol, > but isn't it the general derivation technique that requires analysis and not > the specific definition of SKEYID_e as prf(SKEYID, SKEYID_a | g^xy | CKY-I | > CKY-R | 2). > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > From owner-ipsec@lists.tislabs.com Wed Dec 8 08:45:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27925; Wed, 8 Dec 1999 08:45:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05261 Wed, 8 Dec 1999 10:13:18 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Wed, 8 Dec 1999 07:16:31 -0800 Message-Id: In-Reply-To: <199912070705.XAA04067@potassium.network-alchemy.com> Subject: Re: ID payload on phase 2. MIME-Version: 1.0 TO: dharkins@network-alchemy.com CC: ipsec@lists.tislabs.com, sakane@ydc.co.jp Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm confused. Are you saying that the ID payload contains a selector such as 10.10.10/24/tcp/0? According to the DOI RFC (RFC 2407), Section 4.6.2, the ID payload may contain verious kinds of addresses and names, but not selectors. It could contain 10.10.10/24 but not 10.10.10/24/tcp/0. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: ID payload on phase 2. Author: Non-HP-dharkins (dharkins@network-alchemy.com) at HP-ColSprings,mimegw5 Date: 12/6/99 11:05 PM The ID payload describes the selector for which IP packets will be applied some IPSec transforms. If your selector is for all TCP packets between net 10.10.10/24 and host 10.20.20.2 then that is what would be conveyed in the ID payloads during phase 2. IKE would've been started because there were no IPSec SAs for TCP packets from 10.10.10/24 to 10.20.20.2 and once an IKE SA is established with 10.20.20.2 from the gateway which protects 10.10.10/24 that gateway would initiate a phase 2 exchange with IDs for 10.10.10/24/tcp/0 and 10.20.20.2/tcp/0. Dan. On Tue, 07 Dec 1999 15:09:13 +0900 you wrote > Hi folks, Let me know my questions. > > Which IP address is included in ID payload on Phase 2 ? Draft says that > If there is no ID payload, then ID is the IP address of the IKE peers. > But I'm confusing if there is ID payload. > > Assumed that we will create the SAs between SG1 and SG2. In section 6.2 > in draft-ietf-ipsec-ike-01.txt, 5th paragraph means: > > 1. IDi2, IDr2 means which nodes having the IP address are > protected by the SAs. > IDi2 ----- SG1 ====== SG2 ----- IDr2 > or > SG1(IDi2) ====== SG2(IDr2) > > 2. IDi2, IDr2 means the IP address of the end of the IPsec-SA. > X ----- SG1(IDi2) ===== SG2(IDr2)----- Y > > I think #1 is right because ID is used to decide acceptable proposal. > If so, I will have next question. Which is IP address used as the IP > address of the end of the IPsec-SA ? > Is the end of the IKE-SA's IP address always same to the IPsec-SA's ? > If node has some IP address, then is there a potential that multiple SA > based IP address is created, but same nodes are communicating ? > > node A node B > IPa1 ---- SA1 ----> IPb > IPa2 ---- SA2 ----> IPb > IPa3 ---- SA3 ----> IPb > > I think it is useful something if the IKE peers can exchange the end of > the IP address of IPsec-SA on phase 2. > > Regareds, > > /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Wed Dec 8 10:25:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29216; Wed, 8 Dec 1999 10:25:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05626 Wed, 8 Dec 1999 12:09:11 -0500 (EST) Message-ID: <636C2D109E6CD3119C3600062905FE8F0AEC72@MAIL-CLUSTER.calynet.com> From: Sumit Vakil To: ipsec@lists.tislabs.com Subject: RE: ID payload on phase 2. Date: Wed, 8 Dec 1999 09:05:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm confused. Are you saying that the ID payload > contains a selector > such as 10.10.10/24/tcp/0? > > According to the DOI RFC (RFC 2407), Section 4.6.2, the > ID payload may > contain verious kinds of addresses and names, but not > selectors. It > could contain 10.10.10/24 but not 10.10.10/24/tcp/0. Sure it can. Check out the format of the ID payload from section 4.6.2: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note the protocol id and port fields. Sumit A. Vakil Caly Networks > > Francisco > > > ______________________________ Reply Separator > _________________________________ > Subject: Re: ID payload on phase 2. > Author: Non-HP-dharkins (dharkins@network-alchemy.com) at > HP-ColSprings,mimegw5 > Date: 12/6/99 11:05 PM > > > The ID payload describes the selector for which IP packets will be > applied some IPSec transforms. If your selector is for all > TCP packets > between net 10.10.10/24 and host 10.20.20.2 then that is what would > be conveyed in the ID payloads during phase 2. IKE would've > been started > because there were no IPSec SAs for TCP packets from 10.10.10/24 to > 10.20.20.2 and once an IKE SA is established with 10.20.20.2 from the > gateway which protects 10.10.10/24 that gateway would initiate a phase > 2 exchange with IDs for 10.10.10/24/tcp/0 and 10.20.20.2/tcp/0. > > Dan. > > On Tue, 07 Dec 1999 15:09:13 +0900 you wrote > > Hi folks, Let me know my questions. > > > > Which IP address is included in ID payload on Phase 2 ? > Draft says that > > If there is no ID payload, then ID is the IP address of the > IKE peers. > > But I'm confusing if there is ID payload. > > > > Assumed that we will create the SAs between SG1 and SG2. > In section 6.2 > > in draft-ietf-ipsec-ike-01.txt, 5th paragraph means: > > > > 1. IDi2, IDr2 means which nodes having the IP address are > > protected by the SAs. > > IDi2 ----- SG1 ====== SG2 ----- IDr2 > > or > > SG1(IDi2) ====== SG2(IDr2) > > > > 2. IDi2, IDr2 means the IP address of the end of the > IPsec-SA. > > X ----- SG1(IDi2) ===== SG2(IDr2)----- Y > > > > I think #1 is right because ID is used to decide acceptable > proposal. > > If so, I will have next question. Which is IP address used > as the IP > > address of the end of the IPsec-SA ? > > Is the end of the IKE-SA's IP address always same to the > IPsec-SA's ? > > If node has some IP address, then is there a potential that > multiple SA > > based IP address is created, but same nodes are communicating ? > > > > node A node B > > IPa1 ---- SA1 ----> IPb > > IPa2 ---- SA2 ----> IPb > > IPa3 ---- SA3 ----> IPb > > > > I think it is useful something if the IKE peers can > exchange the end of > > the IP address of IPsec-SA on phase 2. > > > > Regareds, > > > > /Shoichi `NE' Sakane @ KAME project/ > From owner-ipsec@lists.tislabs.com Wed Dec 8 10:25:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29217; Wed, 8 Dec 1999 10:25:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05573 Wed, 8 Dec 1999 11:59:41 -0500 (EST) Message-ID: <384E8F4D.F149F0B2@redcreek.com> Date: Wed, 08 Dec 1999 09:03:09 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > On Tue, 7 Dec 1999, Ricky Charlet wrote: > > I'd like to see dead peer detection be in a dedicated IPsec SA pair per > > peer pair. There are several good things about doing dead peer detection > > this way: > > > This would require a new DOI, no? It's a dedicated phase 2 SA, but it's not > (I claim) an ipsec SA. So a new DOI is needed. > > jan Howdy () Jan, feel free to make other proposals of course, but what I am asking the list to consider IS an IPsec SA seperate from other IPsec SAs and dedicated to carrying (pick your favorite term [keepalive] ) traffic. No new DOI needed here, although I am not opposed to considering such a mechanism. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Wed Dec 8 10:35:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29365; Wed, 8 Dec 1999 10:35:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05618 Wed, 8 Dec 1999 12:08:54 -0500 (EST) Message-Id: <199912081710.JAA08460@potassium.network-alchemy.com> To: francisco_corella@hp.com cc: ipsec@lists.tislabs.com, sakane@ydc.co.jp Subject: Re: ID payload on phase 2. In-reply-to: Your message of "Wed, 08 Dec 1999 07:16:31 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8457.944673017.1@network-alchemy.com> Date: Wed, 08 Dec 1999 09:10:17 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why can't it contain 10.10/24/tcp/0? Look at the figure and accompanying text in 4.6.2 of RFC2407. What do you think the protocol and port fields are for? Dan. On Wed, 08 Dec 1999 07:16:31 PST you wrote > I'm confused. Are you saying that the ID payload contains a selector > such as 10.10.10/24/tcp/0? > > According to the DOI RFC (RFC 2407), Section 4.6.2, the ID payload may > contain verious kinds of addresses and names, but not selectors. It > could contain 10.10.10/24 but not 10.10.10/24/tcp/0. > > Francisco From owner-ipsec@lists.tislabs.com Wed Dec 8 11:09:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29770; Wed, 8 Dec 1999 11:09:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05851 Wed, 8 Dec 1999 12:49:10 -0500 (EST) Message-ID: <384E9AEB.316069AB@redcreek.com> Date: Wed, 08 Dec 1999 09:52:43 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () Here are some thoughts I have come up with or collected so far. It is mostly bad news... * Knowing that each IKE and IPsec SA is 'up' is overkill, we only need to know if each peer is still reachable. * Unsecured heartbeats in the clear leave you open to DOS attack as anybody can spoof you into thinking that your peer is no-responsive. * Heatbeats in IKE will not fly for manual keys or if we ever swap dynamic key maintenance from IKE to something else. * Heartbeats in a seperate and dedicated IPsec or IKE channel does not scale to the remote access problem. * Heartbeats inline with existing IPsec SAs cause accounting difficulties. From owner-ipsec@lists.tislabs.com Wed Dec 8 11:33:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00182; Wed, 8 Dec 1999 11:33:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05971 Wed, 8 Dec 1999 13:18:53 -0500 (EST) Message-ID: <384EA14D.86E5EC23@ire-ma.com> Date: Wed, 08 Dec 1999 13:19:57 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ricky Charlet CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <384E9AEB.316069AB@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet wrote: > * Unsecured heartbeats in the clear leave you open to DOS attack as > anybody can spoof you into thinking that your peer is no-responsive. You don't need spoof heartbeats to make peer "into thinking that your peer is no-responsive". Just spoof any IKE or IPSec traffic. Heartbeats do not increase vulnerability for such attack. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Wed Dec 8 11:55:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00464; Wed, 8 Dec 1999 11:55:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06002 Wed, 8 Dec 1999 13:34:45 -0500 (EST) Date: Wed, 8 Dec 1999 13:38:20 -0500 Message-Id: <199912081838.NAA09200@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rcharlet@redcreek.com Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <384E9AEB.316069AB@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ricky" == Ricky Charlet writes: Ricky> Howdy () Here are some thoughts I have come up with or Ricky> collected so far. It is mostly bad news... Ricky> * Unsecured heartbeats in the clear leave you open to DOS Ricky> attack as anybody can spoof you into thinking that your peer Ricky> is no-responsive. How can you do that? Clearly you can make a down peer appear up, but I don't see how you can make an up peer appear down by spoofing packets. Ricky> * Heatbeats in IKE will not fly for manual keys or if we ever Ricky> swap dynamic key maintenance from IKE to something else. I don't see that manual keying is relevant. By definition, with manual keying you manually manage the SA states at both endpoints. If it's manual then it's not automatic, not even a little bit. So there can never be any keying or SA maintenance protocol of any kind when you're talking about manual keying. Non-IKE? The subject is keepalives in or for the benefit of IKE. If you're not doing IKE then you can solve the problem in that new context, if you wish to (which presumably you will). Ricky> * Heartbeats in a seperate and dedicated IPsec or IKE channel Ricky> does not scale to the remote access problem. Ricky> * Heartbeats inline with existing IPsec SAs cause accounting Ricky> difficulties. I don't agree. If you have a clear way of recognizing heartbeat messages then the accounting is obviously a non-issue. The more basic issue, as Jan Vilhuber points out, it how to recognize such messages without a lot of extra processing in the high speed data forwarding path. There's only one field I can see that will do this, but the price may be too high. Clearly every security gateway has to look at the "next header" field. So a new IP protocol number could be used for heartbeats without forcing the IPSEC processor to look at anything it isn't already looking at. Whether the numbers authority is thrilled about the notion of using up a number for this is another question... paul From owner-ipsec@lists.tislabs.com Wed Dec 8 13:15:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01835; Wed, 8 Dec 1999 13:15:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06294 Wed, 8 Dec 1999 14:45:29 -0500 (EST) Message-Id: <199912081949.OAA17717@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Wed, 08 Dec 1999 09:17:12 EST." <384E6868.BC59AFAD@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Dec 1999 14:49:06 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> Doing heartbeats over IKE SA or IPSec SA is not free - i.e. the Slava> gateway connected to 1000 Clients needs 1000 addtional heartbeat Slava> IPSec SAs to negotiate and maintain - very ugly! I agree. I would advocate in the gateway->client case sending an ICMP ping to the client's internal address, from the gateway's internal address on the primary phase 2 SA. This ought to fit into the typical setup's SPD. Slava> I am still not convinced about security implications of unsecure Slava> hearbeats - and would be interested in what people think. I'm not suggesting that heartbeats be insecure. Rather than IKE needs something to help debugging. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Wed Dec 8 13:24:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01964; Wed, 8 Dec 1999 13:24:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06341 Wed, 8 Dec 1999 14:54:00 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD4D4@exchange> From: Andrew Krywaniuk To: Paul Koning Cc: rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Wed, 8 Dec 1999 14:59:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Ricky> * Unsecured heartbeats in the clear leave you open to DOS > Ricky> attack as anybody can spoof you into thinking that your peer > Ricky> is no-responsive. > > How can you do that? Clearly you can make a down peer appear up, but > I don't see how you can make an up peer appear down by spoofing > packets. Didn't you know? You just spoof an anti-packet. When the packet and anti-packet collide they annihalate each other. The resulting EMP takes down your gateway, causing DoS. Obviously we can't deal with the non-responsiveness issue. The only way to spoof non-responsiveness is for the attacker to remove packets from the wire, and if they can do that then they don't need any help effecting a DoS attack. Maybe Ricky was saying that if we were to tear down the channel if we received a badly formatted packet from the peer then we would be vulnerable to DoS. That's why any good heartbeat protocol has to ignore any packets that could have been spoofed. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Dec 8 13:33:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02054; Wed, 8 Dec 1999 13:33:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06398 Wed, 8 Dec 1999 15:15:39 -0500 (EST) Message-ID: <384EBCA2.3DDA6C0A@ire-ma.com> Date: Wed, 08 Dec 1999 15:16:34 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912081949.OAA17717@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael C. Richardson" wrote: > I agree. > I would advocate in the gateway->client case sending an ICMP ping to the > client's internal address, from the gateway's internal address on the primary > phase 2 SA. This ought to fit into the typical setup's SPD. What do you mean by "primary" Phase 2 SA? Does it mean that this IPSec SA should allow ICMP? From owner-ipsec@lists.tislabs.com Wed Dec 8 13:36:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02113; Wed, 8 Dec 1999 13:36:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06452 Wed, 8 Dec 1999 15:21:54 -0500 (EST) To: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Wed, 8 Dec 1999 08:47:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81CFFFB@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > Sent: 08 December 1999 03:14 > To: Michael C. Richardson > Cc: ipsec@lists.tislabs.com > Subject: Re: Heartbeats (was RE: keepalives) > > > Just a thought - if we have IKE-to-IKE IPSec ESP heartbeat > channel (probably with transport encapsulation) using port > 500 - we would need > somehow to figure out how to distinguish it from IKE port 500 > negotiation traffic which is not subjected to IPSec. If we use transport ESP for the heartbeat then it should be on different port numbers. Chris From owner-ipsec@lists.tislabs.com Wed Dec 8 13:37:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02132; Wed, 8 Dec 1999 13:37:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06455 Wed, 8 Dec 1999 15:21:56 -0500 (EST) Message-Id: <199912080048.BAA07242@waldorf.appli.se> To: Shoichi Sakane cc: tjenkins@TimeStep.com, msa@hemuli.tte.vtt.fi, ipsec@lists.tislabs.com Subject: Re: interpretation of SA bundle. In-reply-to: Your message of "Wed, 08 Dec 1999 08:23:24 +0900." <199912072323.IAA17886@ghost.wide.ydc.co.jp> Date: Wed, 08 Dec 1999 01:48:52 +0100 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wasn't this issue resolved and phrased somewhere? Son-of-ike perhaps? As I think Tim pointed out, the list had a rough consensus that only sane (useful) ordering should be applied to the packets, no matter what ordering the protocols have in the IKE SA payload. The reason being that limiting flexibility and thus complexity of IKE will improve interoperability. Besides, people not knowing exactly what they are doing, will not be able to do useless bundles, like compression of encrypted data (if the encryption is at least semik-good its output will look random, thus not compress well). or put AH inside ESP, thus wasting processing time on decryption before detecting that the packet was bad and needs to be dropped. Hence, the only sane ordering is (in outbound processing order): IPCOMP, ESP, AH. And since only one order is sane, it does not matter what order it is in the IKE SA payload. The only drawback I can see with this approach is that, when someday a fourth protocol enters hte picture, things might not be clear at all anymore. But... does anyone expect a fourth protocol? Wrt tunnel and transport, same thing there, reduce complexity by limiting the wire format to the useful variants, i.e. make tunnel mode just have one extra IP header even if two or more IPsec protocols are applied to it. Essentially this means that the encapsulation mode is really an attribute of the suite, or bundle, rather than each individual ly negotiated niklas. As mixed encapsulation modes in IKE's negotiation creates confusion as to what mode to chose for the bundle, requuire all to be the same. Niklas > Date: Wed, 8 Dec 1999 08:23:24 +0900 (JST) > From: Shoichi Sakane > > > > > Node A sends a proposal including AH tunnel mode followed by ESP > > > tunnel > > > > mode. In this case, we should interpreted to be created IP > > > payload by > > > > using this SA, > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > > > 2. [outer IP][ESP][AH][inner IP][ULP] > > > > 3. [outer IP][AH][inner IP][ESP][inner IP'][ULP] > > > > 4. [outer IP][ESP][inner IP][AH][inner IP'][ULP] > > > Assuming the proposal order as you stated: 4 (e.g. first apply > > > tunnel+AH, then tunnel+ESP). Note, in (1) AH and in (2) ESP is > > > transport mode, so they don't match your proposal anyway. > > My interpretation is #3. I think the order of proposal and transform > means the order of security protocal header in IP packet. > > > > The result should depend on the ordering in the proposal? I don't know > > > about IKE, but I can express all of the above combinations in my > > > policy file, and the kernel IPSEC machinery can do them. > > I can do that. On IKE negotiation, it is only thing that the order of > proposal express local policy file that you say. So I clarify the > interpretation of the order. > > > First, let's be explicit about how this was proposed. If this was > > proposed as a single SA payload with multiple proposal payloads > > with the same number, then: > > I assumed what you say. Additionally, there are encapsulation mode > in each attributes. That is like below: > > SA payload > Proposal: #1 AH > Transform: #1 HMAC-SHA > Attributes: Tunnel > Proposal: #1 ESP > Transform: #1 ES_3DES > Attributes: Tunnel > > > We discussed this and tested this at a bake-offs quite some time ago and > > the concensus seemed to be that the order of application was not as > > proposed, but as to what made sense. That order was (outbound processing) > > IPCOMP before ESP before AH, no matter what the order of proposal. > > > Secondly, the attributes across the proposals are to be consistent, > > and that they must apply to the bundle as a whole. [Aside: this is > > specifically called an SA suite in the MIBs.] This means that a > > bundle (of this type) is all transport mode or all tunnel mode. > > Do you say that each attributes of multiple proposal with same number > MUST have same transport mode ? > > > This means that the correct answer for the above questions is 1. > > #1 is first applyed ESP tunnel, then second AH transport. Am I missing ? > > > > > Another case, Node A sends a proposal including AH transport mode > > > followed > > > > by ESP tunnel mode. > > > > > > > > 1. [outer IP][AH][ESP][inner IP][ULP] > > > > 2. [outer IP][ESP][inner IP][AH][ULP] > > > > > > > > I think there is not these rules of interpretation in any drafts. > > > > > > The case 2 (e.g. first apply AH, then tunnel+ESP). I guess the rule > > > should just state: apply strictly in proposed order. > > > Again, with the same assumptions, the second case is inconsistent. > > However, our implementation will convert the transport mode to > > tunnel, and apply tunnel to the whole thing. Therefore, the answer > > is 1. > > Regarding to what you say, the correct answer is not to be accepted > the proposal of mixed both transport and tunnel mode ? > > > I third the suggestion that this needs to be clearer. Our implementation > > originally did what Markku's did. It no longer does. > > Our kernel can do any combination and many nesting, but I don't know > the currect way to express these combination and nesting on IKE. > > Regards, > > /Shoichi `NE' Sakane @ KAME project/ > From owner-ipsec@lists.tislabs.com Wed Dec 8 13:37:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02143; Wed, 8 Dec 1999 13:37:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06462 Wed, 8 Dec 1999 15:22:53 -0500 (EST) Message-Id: <199912081920.LAA25848@ha1mpk-mail.eng.sun.com> Date: Wed, 8 Dec 1999 11:10:41 -0800 (PST) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: cookie verification To: bkavsan@ire-ma.com, sami.vaarala@netseal.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FFSUb201207NGkOX6XD4WA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_28 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My interpretation of the IKE RFC agrees with Sami's analysis. In IKE, the responder needs to store state from the very first message received from the initiator -- at the very least, SAi_b. Storing the responder's cookie along with this state isn't that much additional overhead (in proportion to the overhead of storing other required info). Having done so, a responder can verify cookies received in subsequent messages by a direct comparison to the saved value. So even though the cookie text in RFC 2409 matches what's in the Photuris draft, IKE really doesn't use cookies for anti-clogging. I have written a prototype IKE implemantation in Java and even though I have a verifyCookie() method, I never need to call it for the reason stated above. vipul > Bronislav, > > > Sami - excellent overview! That's exactly what I was looking for, > > thank you very much! > > In summary - because in the current IKE the cookies are not fully "baked" > yet :) > > - any random or pseudo-random values will work just fine - and with some > future > > standardization in this area - the value of intelligent cookies in IKE can > be > > enhanced. > > I must add a disclaimer to my post -- it was intended to convey my > personal interpretation of the specifications. It would be nice if > someone with more authority on the subject would give a clean > description of cookies and whether my analysis is correct :) > > It would be interesting to know if there is anything real to be > gained by using more "intelligent" cookies, like the ones I described > in the post (they are actually used by our implementation). > > > Until this is the case - all RFC2408 MUSTs about cookie generation should > be > > interpreted as MAY, right? > > In my interpretation, yes. The cookie requirements in ISAKMP were > lifted almost word-for-word from Photuris, which uses the cookies > usefully to prevent state creation in denial-of-service attacks. > I must stress that as far as I understand, ISAKMP *could* use a > similar mechanism (indeed, there is a note of a "header exchange" > which is not elaborated further), although IKE does not (currently) > take advantage of it. > > As far as I see it, the only real requirement for IKE is that the > cookies must be unpredictable to an outsider; the method of creating > them by hashing "stuff" (including IP addresses) fulfills that goal. > > Sami > > -- > Sami Vaarala (sami.vaarala@netseal.com) > NetSeal Technologies > http://www.netseal.com/ > > From owner-ipsec@lists.tislabs.com Wed Dec 8 13:39:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02174; Wed, 8 Dec 1999 13:39:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06467 Wed, 8 Dec 1999 15:23:03 -0500 (EST) Message-Id: <199912082025.MAA10211@gallium.network-alchemy.com> To: "Michael C. Richardson" cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-reply-to: Your message of "Wed, 08 Dec 1999 14:49:06 EST." <199912081949.OAA17717@istari.sandelman.ottawa.on.ca> Date: Wed, 08 Dec 1999 12:25:36 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FWIW, I'm aware of three implementations that use the following private ISAKMP notify status types for an IKE "ping" using protected ISAKMP NOTIFY's. request - 30000 response - 30002 Derrell From owner-ipsec@lists.tislabs.com Wed Dec 8 13:58:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02661; Wed, 8 Dec 1999 13:58:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06559 Wed, 8 Dec 1999 15:47:55 -0500 (EST) Message-ID: <384EC4B3.D592573F@redcreek.com> Date: Wed, 08 Dec 1999 12:50:59 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <384E9AEB.316069AB@redcreek.com> <199912081838.NAA09200@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, Paul Koning wrote: > > >>>>> "Ricky" == Ricky Charlet writes: > > Ricky> * Heatbeats in IKE will not fly for manual keys or if we ever > Ricky> swap dynamic key maintenance from IKE to something else. > > I don't see that manual keying is relevant. By definition, with > manual keying you manually manage the SA states at both endpoints. If > it's manual then it's not automatic, not even a little bit. So there > can never be any keying or SA maintenance protocol of any kind when > you're talking about manual keying. > > Non-IKE? The subject is keepalives in or for the benefit of IKE. If > you're not doing IKE then you can solve the problem in that new > context, if you wish to (which presumably you will). If it's for the benefit of IKE only, then why not just rely upon either ack'd or periodic one-way notifies, and end this discussion? Scott From owner-ipsec@lists.tislabs.com Wed Dec 8 14:43:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08056; Wed, 8 Dec 1999 14:43:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06811 Wed, 8 Dec 1999 16:29:08 -0500 (EST) Message-Id: <199912082132.QAA17874@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Wed, 08 Dec 1999 15:16:34 EST." <384EBCA2.3DDA6C0A@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Dec 1999 16:32:46 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> "Michael C. Richardson" wrote: >> I agree. I would advocate in the gateway->client case sending an ICMP >> ping to the client's internal address, from the gateway's internal >> address on the primary phase 2 SA. This ought to fit into the typical >> setup's SPD. Slava> What do you mean by "primary" Phase 2 SA? Does it mean that this Slava> IPSec SA should allow ICMP? I mean, if you have only one phase 2 SA, then you can use it. If you have multiple phase 2 SAs, or you have accounting issues, then you shouldn't mind creating an ICMP-only SA. My use of "primary" was confusing. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Wed Dec 8 15:16:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08586; Wed, 8 Dec 1999 15:16:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06913 Wed, 8 Dec 1999 16:59:26 -0500 (EST) Message-ID: <384ED503.C60FE0CE@ire-ma.com> Date: Wed, 08 Dec 1999 17:00:35 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912082132.QAA17874@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael C. Richardson" wrote: > I mean, if you have only one phase 2 SA, then you can use it. If you have > multiple phase 2 SAs, or you have accounting issues, then you shouldn't mind > creating an ICMP-only SA. > My use of "primary" was confusing. So, you advocating creating special ICMP heartbeat IPSec SA that terminates on the gateway (ESP/Transport)? I thought you didn't like the overhead and complexity? From owner-ipsec@lists.tislabs.com Wed Dec 8 15:22:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08656; Wed, 8 Dec 1999 15:22:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06990 Wed, 8 Dec 1999 17:21:54 -0500 (EST) Message-Id: <199912082225.RAA17978@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Wed, 08 Dec 1999 17:00:35 EST." <384ED503.C60FE0CE@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Dec 1999 17:25:33 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> "Michael C. Richardson" wrote: >> I mean, if you have only one phase 2 SA, then you can use it. If you >> have multiple phase 2 SAs, or you have accounting issues, then you >> shouldn't mind creating an ICMP-only SA. My use of "primary" was >> confusing. Slava> So, you advocating creating special ICMP heartbeat IPSec SA that Slava> terminates on the gateway (ESP/Transport)? I thought you didn't Slava> like the overhead and complexity? No. I am suggesting that one should always try and use an existing SA, but if there isn't one that satisfies the requirements, then create one if you can afford to, or deal without heartbeat. I don't see any complexity, since you see the heartbeat coming out of the descryption routines, and not even pass it to the routing engine. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Wed Dec 8 15:33:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08978; Wed, 8 Dec 1999 15:33:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06978 Wed, 8 Dec 1999 17:18:32 -0500 (EST) Message-ID: <384EDA0E.A0B6C338@redcreek.com> Date: Wed, 08 Dec 1999 14:22:06 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFD4D4@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > > Ricky> * Unsecured heartbeats in the clear leave you open to DOS > > Ricky> attack as anybody can spoof you into thinking that your peer > > Ricky> is no-responsive. > > > > How can you do that? Clearly you can make a down peer appear up, but > > I don't see how you can make an up peer appear down by spoofing > > packets. > <> > Obviously we can't deal with the non-responsiveness issue. The only way to > spoof non-responsiveness is for the attacker to remove packets from the > wire, and if they can do that then they don't need any help effecting a DoS > attack. <> > > Andrew Howdy () OK. I call in an official "nevermind" on that DOS suceptibility statment above. But I also disagree with the idea that the goal of our heartbeat is for IKE's benefit alone. This discussion certianly started because we were debating IKE continous move Vs. dangeling implementations and IKE heartbeats were originally suggested as a way to help us clean up IKE state more confidently when we can know that a peer is nolonger responsive. But others have mentioned, and I agree, that heartbeat or dead-peer-detection should serve other purposes as well and among these are fail-over action triggering, and alert generation. This is not to say that dead-peer-detection cannot be within IKE. I am just trying to get the list to consider that we do have more options and should examine them. I did find Slava's observation that a seperate channel for heartbeats does not scale to large remote access scenarios devastating to my advocating for seperate channel IPsec SAs. I have to admit that I was thinking of gatway to gatway environments. In my mind, this leaves heartbeats in-channel, inside of IKE or heartbeats in the clear as the only contenders left. What do y'all think? -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Wed Dec 8 15:36:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09015; Wed, 8 Dec 1999 15:36:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06996 Wed, 8 Dec 1999 17:22:14 -0500 (EST) From: jerome@psti.com Message-ID: <19991208172906.A8190@jerome.psti.com> Date: Wed, 8 Dec 1999 17:29:06 -0500 To: ipsec@lists.tislabs.com Subject: diffie-hellman benchmarks Reply-To: jerome@psti.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, i look for benchmarks about diffie-hellman performed over the various oakley groups. anybody got pointer to help me ? From owner-ipsec@lists.tislabs.com Wed Dec 8 15:49:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09129; Wed, 8 Dec 1999 15:49:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07106 Wed, 8 Dec 1999 17:46:12 -0500 (EST) Message-ID: <384EDFCF.13D27FF4@ire-ma.com> Date: Wed, 08 Dec 1999 17:46:39 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912082225.RAA17978@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I doubt that many people will have IPSec SA from Client-to-Gateway that terminate on the gateway - and if this is the case - 1000 Clients connected to the gateway will result in 1000 additional IPSec SAs on the gateway for heartbeat traffic. I don't think that this a good idea. "Michael C. Richardson" wrote: > >>>>> "Slava" == Slava Kavsan writes: > Slava> "Michael C. Richardson" wrote: > > >> I mean, if you have only one phase 2 SA, then you can use it. If you > >> have multiple phase 2 SAs, or you have accounting issues, then you > >> shouldn't mind creating an ICMP-only SA. My use of "primary" was > >> confusing. > > Slava> So, you advocating creating special ICMP heartbeat IPSec SA that > Slava> terminates on the gateway (ESP/Transport)? I thought you didn't > Slava> like the overhead and complexity? > > No. I am suggesting that one should always try and use an existing SA, > but if there isn't one that satisfies the requirements, then create one if > you can afford to, or deal without heartbeat. > I don't see any complexity, since you see the heartbeat coming out > of the descryption routines, and not even pass it to the routing engine. > > :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? > Michael Richardson | Cow#2: No. I'm a duck. > Home: mcr@sandelman.ottawa.on.ca. PGP key available. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-539-4816 http://www.ire.com From owner-ipsec@lists.tislabs.com Wed Dec 8 16:06:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09377; Wed, 8 Dec 1999 16:06:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07079 Wed, 8 Dec 1999 17:43:49 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD5B1@exchange> From: Andrew Krywaniuk To: Ricky Charlet Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Wed, 8 Dec 1999 17:49:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But I also disagree with the idea that the goal of our > heartbeat is for > IKE's benefit alone. This discussion certianly started because we were > debating IKE continous move Vs. dangeling implementations and IKE > heartbeats were originally suggested as a way to help us clean up IKE > state more confidently when we can know that a peer is nolonger > responsive. I disagree. I think this discussion started because we need heartbeats for ipsra. The fact that the same issue came up in the dangling SA thread was a 'triggered coincidence'. > But others have mentioned, and I agree, that heartbeat or > dead-peer-detection should serve other purposes as well and > among these > are fail-over action triggering, and alert generation. This is not to > say that dead-peer-detection cannot be within IKE. I am just trying to > get the list to consider that we do have more options and > should examine > them. I think these are orthagonal issues. The first step will always be detection, but dead peer detection is useless if you don't do anything about it. After you detect the dead peer you have to have a response, which may be an alert, an attempt to reconnect, or a fail-over protocol. Now it may be that the specific heartbeat mechanism will facilitate one or more of these actions, but that's something that we'll have to consider. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Dec 8 16:38:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09810; Wed, 8 Dec 1999 16:38:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07199 Wed, 8 Dec 1999 18:25:47 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 08 Dec 1999 16:28:43 -0700 From: "Hilarie Orman" To: , Subject: Re: diffie-hellman benchmarks Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA07196 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There's the following note re modular exponentiation, which is pretty easy to scale for shorter exponents. And there's a 1995 Crypto paper about 155-bit EC. Hilarie From coderpunks-errors@toad.com Wed Dec 1 00:08:29 1999 Date: Wed, 1 Dec 1999 16:58:04 +1000 (GMT+1000) From: Eric Young To: Thomas Kenneth Zaplachinski cc: coderpunks@toad.com Subject: Re: modular exponentiation in software Sender: owner-coderpunks@toad.com On Tue, 30 Nov 1999, Thomas Kenneth Zaplachinski wrote: > Does anyone have any benchmarks for performing software modular > exponentiation for different key lengths? What would be an acceptable > length of time for performing g^x mod n where x is a random k-bit integer, > n is a k-bit prime, and g is a random k-bit generator for the field Fn, > for k=512, 1024, 2048, and 4096? Some just generated numbers :-). mul 256 ^ 256 % 256 -> 1.446ms mul 512 ^ 512 % 512 -> 8.430ms mul 1024 ^ 1024 % 1024 -> 53.510ms mul 2048 ^ 2048 % 2048 -> 366.214ms mul 4096 ^ 4096 % 4096 -> 2519.000ms Pentium II 450, Visual C 6.0 + 586 asm. This build is targeted at 512^512%512 eric -- Eric Young | eay@pobox.com From owner-ipsec@lists.tislabs.com Wed Dec 8 16:44:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09870; Wed, 8 Dec 1999 16:44:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA07234 Wed, 8 Dec 1999 18:39:42 -0500 (EST) From: jerome@psti.com Message-ID: <19991208184628.A8512@jerome.psti.com> Date: Wed, 8 Dec 1999 18:46:28 -0500 To: Hilarie Orman , ipsec@lists.tislabs.com Subject: Re: diffie-hellman benchmarks Reply-To: jerome@psti.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2 In-Reply-To: ; from Hilarie Orman on Wed, Dec 08, 1999 at 04:28:43PM -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Dec 08, 1999 at 04:28:43PM -0700, Hilarie Orman wrote: > There's the following note re modular exponentiation, which is > pretty easy to scale for shorter exponents. And there's a > 1995 Crypto paper about 155-bit EC. thanks but i dont think that the benchmarks from eric young take advantage of the particular cases of IPSec (i.e. particular parameters of MODP groups. g=2, FFFF at the begining/end of P, fixed g/p, 2 exponantiations with the same exponant, possibly others im not aware of). Do i overestimate the possible optimisations using the particular cases ? From owner-ipsec@lists.tislabs.com Wed Dec 8 17:47:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12208; Wed, 8 Dec 1999 17:47:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07343 Wed, 8 Dec 1999 19:19:33 -0500 (EST) Message-Id: <199912090023.TAA18151@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Wed, 08 Dec 1999 17:46:39 EST." <384EDFCF.13D27FF4@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Dec 1999 19:23:08 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> I doubt that many people will have IPSec SA from Client-to-Gateway Slava> that terminate on the gateway - and if this is the case - 1000 Slava> Clients connected to the gateway will result in 1000 additional Slava> IPSec SAs on the gateway for heartbeat traffic. I don't think that Slava> this a good idea. To the external address of the gateway, it is true. However, I'll bet that 95% of cases will look something like this: C<==================>Gw<------ A.B/16 ---->S (A.B.10.254) 1.1.1.2 3.4.5.6 A.B.1.1 With the tunnel being from C's assigned address to A.B/16. Note that this will include the gateway's internal address A.B.1.1! If the gateway sends the ping to 1.1.1.2 from A.B.1.1 that requires no new SA, and the client will just respond to it and use the same routing it would for A.B. If there are per-host or per-port SAs involved, then the gateway already has a lot of SAs per client. If the gateway is not part of the A.B/16 network, it is conceivable that it might be "assigned" an address that does appear to be on that network. Note: there isn't really any requirement that the ping response even reach the Gw, so long as it traverses the Gw, and the SAD entry is marked via some LRU algorithm, you can determine which SAs have had traffic recently. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Wed Dec 8 18:07:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15628; Wed, 8 Dec 1999 18:07:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07428 Wed, 8 Dec 1999 19:52:11 -0500 (EST) Message-Id: <199912090055.TAA18192@istari.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: Your message of "Wed, 08 Dec 1999 19:47:51 EST." <384EFC36.46AC3B26@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Dec 1999 19:55:49 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bronislav" == Bronislav Kavsan writes: Bronislav> If gateway protects internal subnet 199.34.57.0/255.255.255.0 Bronislav> and has internal address 199.34.57 27 - how Client would know Bronislav> this internal gateway address in order to ping it? Do you My opinion is that clients don't do heartbeats, since they don't have 2000 SAs that they want to track. Bronislav> suggest have this configure this address in the Policy? I bet Bronislav> you will not find to many product that do this - most (if not Bronislav> all) only know the gateway by it's external address. :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? Michael Richardson | Cow#2: No. I'm a duck. Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Wed Dec 8 18:08:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15969; Wed, 8 Dec 1999 18:08:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07407 Wed, 8 Dec 1999 19:49:01 -0500 (EST) Message-ID: <384EFC36.46AC3B26@ire-ma.com> Date: Wed, 08 Dec 1999 19:47:51 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912090023.TAA18151@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If gateway protects internal subnet 199.34.57.0/255.255.255.0 and has internal address 199.34.57 27 - how Client would know this internal gateway address in order to ping it? Do you suggest have this configure this address in the Policy? I bet you will not find to many product that do this - most (if not all) only know the gateway by it's external address. "Michael C. Richardson" wrote: > >>>>> "Slava" == Slava Kavsan writes: > Slava> I doubt that many people will have IPSec SA from Client-to-Gateway > Slava> that terminate on the gateway - and if this is the case - 1000 > Slava> Clients connected to the gateway will result in 1000 additional > Slava> IPSec SAs on the gateway for heartbeat traffic. I don't think that > Slava> this a good idea. > > To the external address of the gateway, it is true. > > However, I'll bet that 95% of cases will look something like this: > > C<==================>Gw<------ A.B/16 ---->S (A.B.10.254) > 1.1.1.2 3.4.5.6 A.B.1.1 > > With the tunnel being from C's assigned address to A.B/16. Note that this > will include the gateway's internal address A.B.1.1! If the gateway sends > the ping to 1.1.1.2 from A.B.1.1 that requires no new SA, and the client > will just respond to it and use the same routing it would for A.B. > > If there are per-host or per-port SAs involved, then the gateway already > has a lot of SAs per client. If the gateway is not part of the A.B/16 > network, it is conceivable that it might be "assigned" an address that does > appear to be on that network. Note: there isn't really any requirement that > the ping response even reach the Gw, so long as it traverses the Gw, and the > SAD entry is marked via some LRU algorithm, you can determine which SAs > have had traffic recently. > > :!mcr!: | Cow#1: Are you worried about getting Mad Cow Disease? > Michael Richardson | Cow#2: No. I'm a duck. > Home: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec@lists.tislabs.com Wed Dec 8 18:09:06 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16032; Wed, 8 Dec 1999 18:09:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07445 Wed, 8 Dec 1999 19:57:39 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: heartbeats (summary of responses) Date: Wed, 8 Dec 1999 20:03:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF41E1.3B583970" 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_000_01BF41E1.3B583970 Content-Type: text/plain; charset="iso-8859-1" Hi all. It's been a few days since my original post on this subject and there have been a fair number of replies. Thanks to everyone who offered comments. This message is a summary of all replies plus some comments from me. I'm attaching the original message for context: <> Most people expressed an interest in host-referenced heartbeats. However, they disagreed on what mechanism should be used to transport the heartbeats. Some people preferred a phase 1 solution; others preferred a phase 2 solution; a couple of people preferred clear pings. Only a couple of people (Tero) agreed that it is desirable to support more than one kind of heartbeat protocol. Clear Pings: I don't believe that clear pings are an acceptable solution. We can't possibly prevent every kind of DoS attack, but we have an obligation to not make them *easy*. Phase 1 Sa-Referenced Heartbeats: In the absence of phase 1 host-referenced heartbeats, these basically tell you if the SA is still up. Since you have a reliable indication of when the SA is up, an attacker can't induce you to renegotiate (a DoS threat) by sending unauthenticated Notify Invalid Cookies (or spoofing a message with invalid cookies). Also, it speeds up negotiation of phase 2s, since you know ahead of time whether you need to negotiate a phase 1 first. No one showed much interest in this type of heartbeat. Phase 1 Host-Referenced Heartbeats: The biggest problem with this idea is that phase 1 heartbeats seem to be incompatible with dangling SA awareness. We have already established that many vendors are not willing to use the continuous channel model, therefore any phase 1 heartbeat scheme must be dangling SA aware. I know Jan has disputed this, but I think that most of us will want to send heartbeat packets at regular intervals. If you set your heartbeat rate to once every 30 seconds, how many people would want to renegotiate their phase 1 at 30 second intervals (under low memory conditions)? On the other hand, I believe that we could get around this limitation by not permitting dangling SAs, but allowing 'pseudo-dangling' SAs instead. In this scenerio, implementations would not be permitted to delete their phase 1s at will. However, they would be allowed to convert them into a skeletal form (pseudo-phase 1), which contains just enough information to receive heartbeats (and probably, by extension, info modes), but not enough to negotiate QMs or use advanced features. This would kill two birds with one stone. It would allow implementations to save memory by discarding unused phase 1 info, but it would still allow them to send phase 2 deletes without renegotiating the phase 1. It would also allow applications to send host-referenced heartbeat packets in phase 1, which IMHO is the right place to send management-type packets. I know Dan said he would look into using using "inline Isakmp" messages to accomplish this, which is a form of pseudo-phase 1 SA as well; in order to send the message, you still have to keep a state. Instead, why not have the pseudo-phase 1 just store the encryption and authentication objects, plus the iv for info modes... I guess you'd need to track the phase 1 lifetime params as well. Plus the heartbeat info, of course. Anything else? Wouldn't this be easier (and less computationally intensive) than generating/verifying an RSA signature on every heartbeat? (and it wouldn't expose known-plaintext RSA sig pairs to a passive attacker) (P.S. I have to give Slava credit for this idea since I just noticed he proposed it already) The only other concern that I have heard about phase 1 heartbeats is that some people are worried that the IKE daemon may crash independently of the IPSEC task and they don't want a failure in IKE to cause the phase 2 SAs to go away. This may be an issue in load-sharing situations where the two processes may be running on different boxes. Jan suggested that the phase 1 heartbeat inform the peer which phase 2s are still up. I don't think this would be much of an issue if we had phase 1 heartbeats AND acknowledged info modes. (This also assumes that the IKE daemon 'knows' when a phase 2 goes down unpredictably.) I was thinking that probably we would want to use a periodic heartbeat message with a replay counter (i.e. a synchronous uni-directional heartbeat). Derrell commented that some vendors have already implemented a query-type heartbeat protocol. This seems less useful to me than a periodic uni-directional protocol. (How do you know when to query? If you wait until you need to send a packet then you have high latency. If you query on a regular basis then you get the same results as the synchronous protocol, but use twice the bandwidth.) Phase 2 Host-Referenced Heartbeats: This is an alternative to host-referenced heartbeats of the phase 1 variety. The advantage is that they do not rely on the existence of the phase 1 SA, so they are automatically compatible with dangling implementations. Still, they don't solve every possible scenerio. In the same way that a phase 1 heartbeat only tells you that the Isakmp daemon is running and not necessarily that the Ipsec layer is working, there is the possibility that one Ipsec SA may crash but another may continue working. In particular, I'm thinking of load-sharing scenarios where the tunnel endpoint is the same but the SAs are running on different host processors. I'm assuming that we would send them across a black-to-black tunnel. This would normally be used for management traffic, but Jan tells me that l2tp uses it as well. However, it would be easy to tell the l2tp traffic from the heartbeat traffic since the next protocol in the header would be l2tp, not icmp. Someone thought we should define a completely new protocol for ipsec heartbeats. This doesn't seem realistic to me. I suppose if ping was unacceptable we could define a new Isakmp message type and allow it to be interpreted as a heartbeat if it is received on an ipsec tunnel. But asking IANA for a new protocol number just for the heartbeats seems presumptuous. Jan also suggested the possibility of a new doi for heartbeat messages. That wouldn't be such a bad idea for host-referenced heartbeats. After all, they don't need to 'hijack' existing SAs, so there is no reason why they couldn't be negotiated within a completely separate domain. It might make this into a slightly bigger project than I intended, though. This also provides a potential fix for the load-sharing scenario. Since there is no requirement to There is also some potential for legacy support. If an existing host allows negotiation of black-to-black SAs and the SPD allows pings then the legacy host can be monitored for liveliness without any negotiation. I do think we need to support negotiation in the long run, though. A couple of people suggested sending a ping to the red (internal IP). I don't agree with this, since it would then require the peer to have knowledge of the internal IP, which is unnecessary (although I suppose the parameters for this could be negotiated). Phase 2 Sa-Referenced Heartbeats: A couple of people expressed interest in these, mostly as a resource-friendly alternative to host-referenced heartbeats. In remote access scenarios, typically there is only 1 (or only a few) phase 2 SA between the peers; adding a host-referenced heartbeat SA would double the resource requirements (assuming you are dropping the phase 1s). By hijacking an existing phase 2 you can save memory and negotiation time. I also foresaw two other uses: One was a simple solution to the load sharing scenario (sending the heartbeat on a hijacked SA guarantees that the same physical host that is sending the ping is the same one that is transmitting on the SA). The other possibility is that some phase 2 SAs (probably in the VPN backbone) will be deemed 'critical' (in that they guarantee less than 0.01% downtime or such). In order to ensure that these SAs are not only up, but also WORKING (i.e. the state on the peers is synchronized), it might be desirable to send a regular heartbeat message. Jan expressed concern that this would slow down Ipsec processing too much. That depends. How many people verify the source/dest addresses for the tunneled packet against the ones in the SPD? If you are already doing this for every packet then you lose no speed; if you just check the spi currently then adding the check for the IPs would slow you down. But I was thinking, maybe this is another case where using a separate doi would be useful. I wouldn't want to negotiate a separate SAs for the new doi (that would mostly defeat the point), but maybe a doi of IPSEC_MANAGEMENT could be used to identify management traffic that is flowing on an existing Ipsec SA. Jan expressed concern about not interfering with customer billing information, however all the proposed solutions have already taken this into account. Ditto with not allowing heartbeats to interfere with inactivity timers. Tero commented that phase 2 host-referenced heartbeats could be implemented as a special case of phase 2 sa-referenced heartbeats, which is what I originally intended. Heartbeat Negotiation Protocols: I didn't really bring this up before. I assume that we will need to have some kind of general negotiation framework in place (a subject that was discussed briefly and then dropped). In the meantime, I will probably label this an 'experimental future' and use a vendor id; however, since there will undoubtedly be parameters (e.g. heartbeat type, heartbeat frequency, recovery action, IP address to ping, etc.) regardless of which heartbeat format we decide on, maybe we will need a config exchange as well. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. ------_=_NextPart_000_01BF41E1.3B583970 Content-Type: message/rfc822 Content-Description: RE: Heartbeats (was RE: keepalives) Content-Location: ATT-0-E0F91CC478ADD311935400104B6AA8D8-R E%3A%20Heartbeats%20%28was%20RE%3A%20kee palives%29 Message-ID: <319A1C5F94C8D11192DE00805FBBADDFFFC9A2@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Fri, 3 Dec 1999 16:15:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" How about, to get this discussion going, I suggest a format and you (the list) tell me if it seems appropriate. I can put this in a draft if there is interest in standardization. I think that different types of heartbeats (phase 1/phase 2, SA-referenced/host-referenced) provide different services, and we need to support all kinds. I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then search & replace with your favorite term. When I do refer to keep-alives at the end of the document, I use Tim's definition (a mechanism for disabling the peer's inactivity timeout). ---------------------------------------------------------------------------- As I see it, there are two types of heartbeats: phase 1 heartbeats and phase 2 heartbeats. PHASE 1 HEARTBEATS: Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they also tell you that the peer is still there. However, this is a sufficient but not necessary condition. The peer may be a dangling implementation, in which case they may not send phase 1 heartbeats even though they are still running. However, phase 1 heartbeats still have a use because they ensure that the peers will always agree on whether a phase 1 exists. It avoids the clumsiness of one peer trying to send a message on the phase 1, receiving NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase 1 is down and needs to be rekeyed. Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as a means of determining when an SA has gone down is vulnerable to DoS attacks, whereas heartbeats are not. I'm not going to discuss a format for phase 1 heartbeats in this post because IMHO it's not a technically difficult issue. Any one of a million packet formats would suffice (info mode, config mode, acknowledged info mode, some new exchange) and the only real issue is getting a group of people to settle on any particular one. PHASE 2 HEARTBEATS: There are two types of phase 2 heartbeats: host-referenced and SA-referenced. A host-referenced heartbeat is a protocol that runs across a dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a protocol that runs across an existing (user) SA. Host-referenced heartbeats can only be used to detect if the peer is still up and running. Therefore, they are of limited use. (However, the fact that they don't carry any sensitive information means that they they would never need to be deleted before their natural lifetime. Therefore, they would be the most reliable means of detecting if the peer is still alive since there is no possibility of a phase 2 delete being lost.) SA-referenced heartbeats detect if a specific phase 2 SA is still working. They also probably tell you when the peer is not there, since you wouldn't expect a phase 2 SA to disappear without receiving a delete (although I've been hearing some discussion of this recently on the list). However, they are probably the most useful type of heartbeat, which is why I am going to discuss them here. SA-referenced Phase 2 heartbeats are more technically complicated than other heartbeats because: 1) They must not interfere with the peer's inactivity timeouts. 2) They must not disturb any accounting services that may be running. 3) They must not result in any packets ending up on the peer's red network. 4) They must not assume that a phase 1 SA exists between the two peers. It is not, in general, possible to satisfy all of these constraints without some degree of cooperation. Therefore, both peers must be aware of the heartbeat scheme that is being used (i.e. it must be negotiated). In light of these constraints, I propose the following format: Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 and peer 2 replies. In order to distinguish these pings from user traffic, the source and destinations addresses are set to the hosts' black IPs. If either side fails to receive a heartbeat within N*X seconds then they can assume that the SA has gone down (and they should send a delete for it). (If they fail to receive a ping but they receive other traffic on the SA then something has gone wrong and they should log the event). Replay protection is not required, as IPSec automatically provides it. It is not necessary for peer 2 to ever initiate the pings. However, to increase reliability, if peer 2 does not receive a ping during the normal window [X, X*3/2], he may force the issue by initiating a ping in the opposite direction. This technique has the following advantages: 1) It satisfies all of the above constraints. 2) It does not require the host to have any knowledge of the peer's red IP or red subnet. 3) Ping has universal brand-name recognition as a heartbeat protocol. Therefore, no special payload format is required. and the following disadvantages: 1) The SPD must make a specific exception for ping packets between the black IPs. 2) The accounting service should know not to bill the user for this traffic. However, I believe these disadvantages will be inherent in any SA-referenced heartbeat scheme. Note that a Host-referenced heartbeat scheme could be constructed in the same way as an SA-referenced scheme, simply by negotiating a dedicated SA using the black IPs as the endpoints. This could be done in tunnel mode (presumably using the same policy exception that is used for SA-referenced heartbeats) or it could simply be done in transport mode. FUTURE CONSIDERATIONS: One potential limitation of this scheme is that it does not generalize well to keep-alives. The use of ping as a packet format is simple, but it doesn't allow us to specify any additional information (all it says is STILL_CONNECTED). It may be desirable to send extra information in the packet. For example, a simple keep-alive (in the literal sense) scheme would be to take the heartbeat scheme and add one extra bit of information (E.g. STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer that idle timeouts be disabled via. a negotiated attribute of the SA (if feature negotiation ever gets standardized). There is no particular reason to use ping as transport, except for the fact that it is already a universally accepted packet format and requires no approval from IANA. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. ------_=_NextPart_000_01BF41E1.3B583970-- From owner-ipsec@lists.tislabs.com Wed Dec 8 18:31:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20056; Wed, 8 Dec 1999 18:31:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07517 Wed, 8 Dec 1999 20:20:04 -0500 (EST) Message-Id: <9912090136.AA02785@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Thu, 09 Dec 1999 10:36:17 +0900 To: Bronislav Kavsan Cc: Sami Vaarala , ipsec@lists.tislabs.com Subject: Re: cookie verification In-Reply-To: <384E4577.5D27E67E@ire-ma.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The use of IKE Cookie in a draft http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt is better in terms of statelessness. Bronislav Kavsan wrote: >>Sami - excellent overview! That's exactly what I was looking for, thank you very >>much! >>In summary - because in the current IKE the cookies are not fully "baked" yet :) >>- any random or pseudo-random values will work just fine - and with some future >>standardization in this area - the value of intelligent cookies in IKE can be >>enhanced. >> >>Until this is the case - all RFC2408 MUSTs about cookie generation should be >>interpreted as MAY, right? >> >>Sami Vaarala wrote: >> >>> Bronislav Kavsan wrote: >>> > RFC 2408 in Section 2.5.3 contains few MUSTs as well as recommendations >>> > for cookie generation. I am not clear on the "verification of cookie" >>> > part, which is the whole reason for not simply selecting a random number >>> > for cookies value. >>> > >>> > Could someone explain the "standard" technique of generation and >>> > especially subsequent verification of cookies? Does anyone uses this >>> > technique and verifies other vendor cookies? >>> >>> Yes, RFC 2408 is extremely vague about the purpose, creation, and >>> verification >>> of cookies. (It is also vague about a lot of other things, but let's not >>> get >>> into that now ;-). >>> >>> For exchanges without an initial stateless phase (ie all the IKE exchanges), >>> the cookie creation method makes no difference, as long as the cookie >>> generation >>> mechanism is *unpredictable* to an outsider (to serve the weak source IP >>> authentication function). Cookie verification then equals comparison to a >>> cookie >>> value stored in some sort of exchange state. >>> >>> Creating cookies using a hash with public and private data (as suggested by >>> RFC 2408) >>> is good since you do not have to waste random numbers for each cookie >>> (indeed, >>> random numbers are a scarce resource :). Otherwise, use your favorite >>> pseudo-random >>> number generator. >>> >>> However, cookies CAN be made more intelligent, see the Photuris RFC (RFC >>> 2522) >>> for an example of how cookies can be used for a stateless beginning in an >>> exchange. A responder will not have to store any state until the source IP >>> of the initiator has been weakly authenticated. >>> >>> ISAKMP *could* take use of such stateless exchanges; none of the IKE >>> exchanges is "stateless", though, and the stateless nature of cookies is >>> academic for IKE. >>> (In IKE you need to store data from the first initiator message in order to >>> participate in the exchange later). >>> >>> It is possible to write a cookie generation function that allows us to: >>> (1) verify that a cookie was created by us >>> (2) determine the approximate age of the cookie (eg with a 1 second >>> resolution >>> up to 15 minutes) >>> (3) determine the role for which the cookie was created (initiator vs. >>> responder, >>> main mode vs. aggressive mode, source and dest IP address/ports, etc) >>> without storing any cookie-per-cookie state, and by using one hash and one >>> DES >>> operation per cookie verification and creation. >>> >>> This extra information can be used to eg defend against replay/reflection >>> attacks >>> in a exchange-neutral manner (ie the message is dropped even before IKE >>> exchange >>> code is invoked). Having said that, it does not PREVENT such attacks >>> indefinitely. >>> It only serves as extra protection for some period of time after completion >>> of an >>> exchange (and can trivially block interleaved reflections). >>> >>> It would be good to include a better discussion of the cookie security >>> function >>> in a future ISAKMP specification. I would also like to see pseudo-code for >>> a >>> basic implementation, and an example of a stateless application. >>> >>> Sami >>> >>> -- >>> Sami Vaarala (sami.vaarala@netseal.com) >>> NetSeal Technologies >>> http://www.netseal.com/ >> >> >> --^^-- Kanta From owner-ipsec@lists.tislabs.com Wed Dec 8 18:42:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21318; Wed, 8 Dec 1999 18:42:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07537 Wed, 8 Dec 1999 20:23:49 -0500 (EST) Message-ID: <384F0490.1FA838FA@ire-ma.com> Date: Wed, 08 Dec 1999 20:23:29 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael C. Richardson" CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912090055.TAA18192@istari.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael C. Richardson" wrote: > My opinion is that clients don't do heartbeats, since they don't have 2000 > SAs that they want to track. To prevent Clients from detecting dead Gateways or other host - is very restricting in my opinion - for example, it will prevent Client to re-engage with redundant gateways. Heartbeats have be available to any IPSec host that wants to use them. From owner-ipsec@lists.tislabs.com Wed Dec 8 19:07:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24772; Wed, 8 Dec 1999 19:07:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07572 Wed, 8 Dec 1999 20:52:01 -0500 (EST) Message-ID: <384F0B1F.7F005895@ire-ma.com> Date: Wed, 08 Dec 1999 20:51:28 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good summary Andrew! My vote goes to Phase1-based hearbeats using never-going-away IKE SAs (or skeletal ones for resource-restricted implementations - just enough to protect Informational messages). I would also like to suggest using Ack-ed NOTIFY mechanism and not to invent yet another scheme. Heartbeat management messages will also be useful. Andrew Krywaniuk wrote: > Hi all. It's been a few days since my original post on this subject and > there have been a fair number of replies. Thanks to everyone who offered > comments. This message is a summary of all replies plus some comments from > me. > > I'm attaching the original message for context: < keepalives)>> > > Most people expressed an interest in host-referenced heartbeats. However, > they disagreed on what mechanism should be used to transport the heartbeats. > Some people preferred a phase 1 solution; others preferred a phase 2 > solution; a couple of people preferred clear pings. Only a couple of people > (Tero) agreed that it is desirable to support more than one kind of > heartbeat protocol. > > Clear Pings: > > I don't believe that clear pings are an acceptable solution. We can't > possibly prevent every kind of DoS attack, but we have an obligation to not > make them *easy*. > > Phase 1 Sa-Referenced Heartbeats: > > In the absence of phase 1 host-referenced heartbeats, these basically tell > you if the SA is still up. Since you have a reliable indication of when the > SA is up, an attacker can't induce you to renegotiate (a DoS threat) by > sending unauthenticated Notify Invalid Cookies (or spoofing a message with > invalid cookies). Also, it speeds up negotiation of phase 2s, since you know > ahead of time whether you need to negotiate a phase 1 first. No one showed > much interest in this type of heartbeat. > > Phase 1 Host-Referenced Heartbeats: > > The biggest problem with this idea is that phase 1 heartbeats seem to be > incompatible with dangling SA awareness. We have already established that > many vendors are not willing to use the continuous channel model, therefore > any phase 1 heartbeat scheme must be dangling SA aware. > > I know Jan has disputed this, but I think that most of us will want to send > heartbeat packets at regular intervals. If you set your heartbeat rate to > once every 30 seconds, how many people would want to renegotiate their phase > 1 at 30 second intervals (under low memory conditions)? > > On the other hand, I believe that we could get around this limitation by not > permitting dangling SAs, but allowing 'pseudo-dangling' SAs instead. In this > scenerio, implementations would not be permitted to delete their phase 1s at > will. However, they would be allowed to convert them into a skeletal form > (pseudo-phase 1), which contains just enough information to receive > heartbeats (and probably, by extension, info modes), but not enough to > negotiate QMs or use advanced features. > > This would kill two birds with one stone. It would allow implementations to > save memory by discarding unused phase 1 info, but it would still allow them > to send phase 2 deletes without renegotiating the phase 1. It would also > allow applications to send host-referenced heartbeat packets in phase 1, > which IMHO is the right place to send management-type packets. > > I know Dan said he would look into using using "inline Isakmp" messages to > accomplish this, which is a form of pseudo-phase 1 SA as well; in order to > send the message, you still have to keep a state. Instead, why not have the > pseudo-phase 1 just store the encryption and authentication objects, plus > the iv for info modes... I guess you'd need to track the phase 1 lifetime > params as well. Plus the heartbeat info, of course. Anything else? Wouldn't > this be easier (and less computationally intensive) than > generating/verifying an RSA signature on every heartbeat? (and it wouldn't > expose known-plaintext RSA sig pairs to a passive attacker) (P.S. I have to > give Slava credit for this idea since I just noticed he proposed it already) > > The only other concern that I have heard about phase 1 heartbeats is that > some people are worried that the IKE daemon may crash independently of the > IPSEC task and they don't want a failure in IKE to cause the phase 2 SAs to > go away. This may be an issue in load-sharing situations where the two > processes may be running on different boxes. > > Jan suggested that the phase 1 heartbeat inform the peer which phase 2s are > still up. I don't think this would be much of an issue if we had phase 1 > heartbeats AND acknowledged info modes. (This also assumes that the IKE > daemon 'knows' when a phase 2 goes down unpredictably.) > > I was thinking that probably we would want to use a periodic heartbeat > message with a replay counter (i.e. a synchronous uni-directional > heartbeat). Derrell commented that some vendors have already implemented a > query-type heartbeat protocol. This seems less useful to me than a periodic > uni-directional protocol. (How do you know when to query? If you wait until > you need to send a packet then you have high latency. If you query on a > regular basis then you get the same results as the synchronous protocol, but > use twice the bandwidth.) > > Phase 2 Host-Referenced Heartbeats: > > This is an alternative to host-referenced heartbeats of the phase 1 variety. > The advantage is that they do not rely on the existence of the phase 1 SA, > so they are automatically compatible with dangling implementations. > > Still, they don't solve every possible scenerio. In the same way that a > phase 1 heartbeat only tells you that the Isakmp daemon is running and not > necessarily that the Ipsec layer is working, there is the possibility that > one Ipsec SA may crash but another may continue working. In particular, I'm > thinking of load-sharing scenarios where the tunnel endpoint is the same but > the SAs are running on different host processors. > > I'm assuming that we would send them across a black-to-black tunnel. This > would normally be used for management traffic, but Jan tells me that l2tp > uses it as well. However, it would be easy to tell the l2tp traffic from the > heartbeat traffic since the next protocol in the header would be l2tp, not > icmp. > > Someone thought we should define a completely new protocol for ipsec > heartbeats. This doesn't seem realistic to me. I suppose if ping was > unacceptable we could define a new Isakmp message type and allow it to be > interpreted as a heartbeat if it is received on an ipsec tunnel. But asking > IANA for a new protocol number just for the heartbeats seems presumptuous. > > Jan also suggested the possibility of a new doi for heartbeat messages. That > wouldn't be such a bad idea for host-referenced heartbeats. After all, they > don't need to 'hijack' existing SAs, so there is no reason why they couldn't > be negotiated within a completely separate domain. It might make this into a > slightly bigger project than I intended, though. This also provides a > potential fix for the load-sharing scenario. Since there is no requirement > to > > There is also some potential for legacy support. If an existing host allows > negotiation of black-to-black SAs and the SPD allows pings then the legacy > host can be monitored for liveliness without any negotiation. I do think we > need to support negotiation in the long run, though. > > A couple of people suggested sending a ping to the red (internal IP). I > don't agree with this, since it would then require the peer to have > knowledge of the internal IP, which is unnecessary (although I suppose the > parameters for this could be negotiated). > > Phase 2 Sa-Referenced Heartbeats: > > A couple of people expressed interest in these, mostly as a > resource-friendly alternative to host-referenced heartbeats. In remote > access scenarios, typically there is only 1 (or only a few) phase 2 SA > between the peers; adding a host-referenced heartbeat SA would double the > resource requirements (assuming you are dropping the phase 1s). By hijacking > an existing phase 2 you can save memory and negotiation time. > > I also foresaw two other uses: One was a simple solution to the load sharing > scenario (sending the heartbeat on a hijacked SA guarantees that the same > physical host that is sending the ping is the same one that is transmitting > on the SA). The other possibility is that some phase 2 SAs (probably in the > VPN backbone) will be deemed 'critical' (in that they guarantee less than > 0.01% downtime or such). In order to ensure that these SAs are not only up, > but also WORKING (i.e. the state on the peers is synchronized), it might be > desirable to send a regular heartbeat message. > > Jan expressed concern that this would slow down Ipsec processing too much. > That depends. How many people verify the source/dest addresses for the > tunneled packet against the ones in the SPD? If you are already doing this > for every packet then you lose no speed; if you just check the spi currently > then adding the check for the IPs would slow you down. > > But I was thinking, maybe this is another case where using a separate doi > would be useful. I wouldn't want to negotiate a separate SAs for the new doi > (that would mostly defeat the point), but maybe a doi of IPSEC_MANAGEMENT > could be used to identify management traffic that is flowing on an existing > Ipsec SA. > > Jan expressed concern about not interfering with customer billing > information, however all the proposed solutions have already taken this into > account. Ditto with not allowing heartbeats to interfere with inactivity > timers. > > Tero commented that phase 2 host-referenced heartbeats could be implemented > as a special case of phase 2 sa-referenced heartbeats, which is what I > originally intended. > > Heartbeat Negotiation Protocols: > > I didn't really bring this up before. I assume that we will need to have > some kind of general negotiation framework in place (a subject that was > discussed briefly and then dropped). In the meantime, I will probably label > this an 'experimental future' and use a vendor id; however, since there will > undoubtedly be parameters (e.g. heartbeat type, heartbeat frequency, > recovery action, IP address to ping, etc.) regardless of which heartbeat > format we decide on, maybe we will need a config exchange as well. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > > ------------------------------------------------------------------------ > > Subject: RE: Heartbeats (was RE: keepalives) > Date: Fri, 3 Dec 1999 16:15:16 -0500 > From: Andrew Krywaniuk > To: ipsec@lists.tislabs.com > > How about, to get this discussion going, I suggest a format and you (the > list) tell me if it seems appropriate. I can put this in a draft if there is > interest in standardization. > > I think that different types of heartbeats (phase 1/phase 2, > SA-referenced/host-referenced) provide different services, and we need to > support all kinds. > > I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then > search & replace with your favorite term. When I do refer to keep-alives at > the end of the document, I use Tim's definition (a mechanism for disabling > the peer's inactivity timeout). > > ---------------------------------------------------------------------------- > > As I see it, there are two types of heartbeats: phase 1 heartbeats and phase > 2 heartbeats. > > PHASE 1 HEARTBEATS: > > Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they > also tell you that the peer is still there. However, this is a sufficient > but not necessary condition. The peer may be a dangling implementation, in > which case they may not send phase 1 heartbeats even though they are still > running. > > However, phase 1 heartbeats still have a use because they ensure that the > peers will always agree on whether a phase 1 exists. It avoids the > clumsiness of one peer trying to send a message on the phase 1, receiving > NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase > 1 is down and needs to be rekeyed. > > Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as > a means of determining when an SA has gone down is vulnerable to DoS > attacks, whereas heartbeats are not. > > I'm not going to discuss a format for phase 1 heartbeats in this post > because IMHO it's not a technically difficult issue. Any one of a million > packet formats would suffice (info mode, config mode, acknowledged info > mode, some new exchange) and the only real issue is getting a group of > people to settle on any particular one. > > PHASE 2 HEARTBEATS: > > There are two types of phase 2 heartbeats: host-referenced and > SA-referenced. A host-referenced heartbeat is a protocol that runs across a > dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a > protocol that runs across an existing (user) SA. > > Host-referenced heartbeats can only be used to detect if the peer is still > up and running. Therefore, they are of limited use. (However, the fact that > they don't carry any sensitive information means that they they would never > need to be deleted before their natural lifetime. Therefore, they would be > the most reliable means of detecting if the peer is still alive since there > is no possibility of a phase 2 delete being lost.) > > SA-referenced heartbeats detect if a specific phase 2 SA is still working. > They also probably tell you when the peer is not there, since you wouldn't > expect a phase 2 SA to disappear without receiving a delete (although I've > been hearing some discussion of this recently on the list). However, they > are probably the most useful type of heartbeat, which is why I am going to > discuss them here. > > SA-referenced Phase 2 heartbeats are more technically complicated than other > heartbeats because: > > 1) They must not interfere with the peer's inactivity timeouts. > 2) They must not disturb any accounting services that may be running. > 3) They must not result in any packets ending up on the peer's red network. > 4) They must not assume that a phase 1 SA exists between the two peers. > > It is not, in general, possible to satisfy all of these constraints without > some degree of cooperation. Therefore, both peers must be aware of the > heartbeat scheme that is being used (i.e. it must be negotiated). > > In light of these constraints, I propose the following format: > > Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 > and peer 2 replies. In order to distinguish these pings from user traffic, > the source and destinations addresses are set to the hosts' black IPs. If > either side fails to receive a heartbeat within N*X seconds then they can > assume that the SA has gone down (and they should send a delete for it). (If > they fail to receive a ping but they receive other traffic on the SA then > something has gone wrong and they should log the event). Replay protection > is not required, as IPSec automatically provides it. > > It is not necessary for peer 2 to ever initiate the pings. However, to > increase reliability, if peer 2 does not receive a ping during the normal > window [X, X*3/2], he may force the issue by initiating a ping in the > opposite direction. > > This technique has the following advantages: > > 1) It satisfies all of the above constraints. > 2) It does not require the host to have any knowledge of the peer's red IP > or red subnet. > 3) Ping has universal brand-name recognition as a heartbeat protocol. > Therefore, no special payload format is required. > > and the following disadvantages: > > 1) The SPD must make a specific exception for ping packets between the black > IPs. > 2) The accounting service should know not to bill the user for this traffic. > > However, I believe these disadvantages will be inherent in any SA-referenced > heartbeat scheme. > > Note that a Host-referenced heartbeat scheme could be constructed in the > same way as an SA-referenced scheme, simply by negotiating a dedicated SA > using the black IPs as the endpoints. This could be done in tunnel mode > (presumably using the same policy exception that is used for SA-referenced > heartbeats) or it could simply be done in transport mode. > > FUTURE CONSIDERATIONS: > > One potential limitation of this scheme is that it does not generalize well > to keep-alives. The use of ping as a packet format is simple, but it doesn't > allow us to specify any additional information (all it says is > STILL_CONNECTED). It may be desirable to send extra information in the > packet. For example, a simple keep-alive (in the literal sense) scheme would > be to take the heartbeat scheme and add one extra bit of information (E.g. > STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer > that idle timeouts be disabled via. a negotiated attribute of the SA (if > feature negotiation ever gets standardized). > > There is no particular reason to use ping as transport, except for the fact > that it is already a universally accepted packet format and requires no > approval from IANA. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Dec 8 19:11:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25196; Wed, 8 Dec 1999 19:10:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07621 Wed, 8 Dec 1999 21:10:54 -0500 (EST) Message-ID: <384F106A.216A591@redcreek.com> Date: Wed, 08 Dec 1999 18:14:02 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Krywaniuk CC: Ricky Charlet , ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFD5B1@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > But I also disagree with the idea that the goal of our > > heartbeat is for > > IKE's benefit alone. This discussion certianly started because we were > > debating IKE continous move Vs. dangeling implementations and IKE > > heartbeats were originally suggested as a way to help us clean up IKE > > state more confidently when we can know that a peer is nolonger > > responsive. > > I disagree. I think this discussion started because we need heartbeats for > ipsra. The fact that the same issue came up in the dangling SA thread was a > 'triggered coincidence'. This issue touches remote access, but that is not the extent of it. I have no idea what a triggered coincidence is (other than an oxymoron), but the fact is that this issue is being discussed on the general ipsec list, not the ipsra list, and there is a reason for that. > > But others have mentioned, and I agree, that heartbeat or > > dead-peer-detection should serve other purposes as well and > > among these > > are fail-over action triggering, and alert generation. This is not to > > say that dead-peer-detection cannot be within IKE. I am just trying to > > get the list to consider that we do have more options and > > should examine > > them. > > I think these are orthagonal issues. The first step will always be > detection, but dead peer detection is useless if you don't do anything about > it. After you detect the dead peer you have to have a response, which may be > an alert, an attempt to reconnect, or a fail-over protocol. > I think you mean "orthogonal", and "independent" would perhaps be more forthright, even if it is still wrong. We want to detect the fact that a peer is no longer there for the express purpose of taking some action - these are hardly unrelated, independent, or orthogonal. I introduced the term "dead peer detection" into this discussion originally because I believe that this is a dimension of the discussion that was being neglected. There are (at least) 2 ways to look at this: in one, we expect the remote peer to actively announce that it is still alive; in another, we detect that the remote peer is no longer present using various cues which we have yet to discuss. There seem to be a few issues here: first, there seems to be a requirement that we detect when we are black-holing packets. Second, there seems to be a requirement for detecting when a remote access client terminates a session in order to facilitate accounting. These are closely related, and not unique to the remote access scenario. Does anyone have additional requirements we are trying to satisfy? Scott From owner-ipsec@lists.tislabs.com Wed Dec 8 19:37:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA28474; Wed, 8 Dec 1999 19:37:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07644 Wed, 8 Dec 1999 21:13:50 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 8 Dec 1999 18:17:03 -0800 (PST) From: Jan Vilhuber To: Slava Kavsan cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) In-Reply-To: <384F0B1F.7F005895@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Dec 1999, Slava Kavsan wrote: > Good summary Andrew! > > My vote goes to Phase1-based hearbeats using never-going-away IKE SAs I still disagree with this. It goes counter to what has been discussed previously about continuous channel mode. I don't want to require anyone to HAVE to keep their IKE SA up. Only when needed. The question I've seen is: Well, won't you need it all the time? Answer: No. In some cases, when you might have keepalives only with ipsec traffic (for dial-up scnearios), you may have the link go quiet for extended periods of time, during which you certainly do NOT need to keep the IKE SA around. The normal negotiated lifetimes apply, and after that *poof* it goes away (on both sides, I might add). When more ipsec traffic needs to be sent, and new keepalives need to be sent, you renegotiate a phase 1. > (or > skeletal ones for resource-restricted implementations - just enough to protect > Informational messages). I would also like to suggest using Ack-ed NOTIFY > mechanism and not to invent yet another scheme. Heartbeat management messages > will also be useful. > I don't think we need to burden this scheme with more management messages. All you need to do is to negotiate the kind of keepalive you want (continuous, or only with ipsec traffic) and what frequency (if applicable), and so on. After that, don't worry about it. Uni-directional heartbeats (to be negotiated by each side, i.e. each side requests heartbeats to be sent from the other side) is acceptable, too, I think, for the long run. I understand the argument about this cutting messages down by half. As long as you can negotiate the frequency and the type up front, I think this is acceptable (despite what some of us already have implemented (in more than one way)). jan > Andrew Krywaniuk wrote: > > > Hi all. It's been a few days since my original post on this subject and > > there have been a fair number of replies. Thanks to everyone who offered > > comments. This message is a summary of all replies plus some comments from > > me. > > > > I'm attaching the original message for context: < > keepalives)>> > > > > Most people expressed an interest in host-referenced heartbeats. However, > > they disagreed on what mechanism should be used to transport the heartbeats. > > Some people preferred a phase 1 solution; others preferred a phase 2 > > solution; a couple of people preferred clear pings. Only a couple of people > > (Tero) agreed that it is desirable to support more than one kind of > > heartbeat protocol. > > > > Clear Pings: > > > > I don't believe that clear pings are an acceptable solution. We can't > > possibly prevent every kind of DoS attack, but we have an obligation to not > > make them *easy*. > > > > Phase 1 Sa-Referenced Heartbeats: > > > > In the absence of phase 1 host-referenced heartbeats, these basically tell > > you if the SA is still up. Since you have a reliable indication of when the > > SA is up, an attacker can't induce you to renegotiate (a DoS threat) by > > sending unauthenticated Notify Invalid Cookies (or spoofing a message with > > invalid cookies). Also, it speeds up negotiation of phase 2s, since you know > > ahead of time whether you need to negotiate a phase 1 first. No one showed > > much interest in this type of heartbeat. > > > > Phase 1 Host-Referenced Heartbeats: > > > > The biggest problem with this idea is that phase 1 heartbeats seem to be > > incompatible with dangling SA awareness. We have already established that > > many vendors are not willing to use the continuous channel model, therefore > > any phase 1 heartbeat scheme must be dangling SA aware. > > > > I know Jan has disputed this, but I think that most of us will want to send > > heartbeat packets at regular intervals. If you set your heartbeat rate to > > once every 30 seconds, how many people would want to renegotiate their phase > > 1 at 30 second intervals (under low memory conditions)? > > > > On the other hand, I believe that we could get around this limitation by not > > permitting dangling SAs, but allowing 'pseudo-dangling' SAs instead. In this > > scenerio, implementations would not be permitted to delete their phase 1s at > > will. However, they would be allowed to convert them into a skeletal form > > (pseudo-phase 1), which contains just enough information to receive > > heartbeats (and probably, by extension, info modes), but not enough to > > negotiate QMs or use advanced features. > > > > This would kill two birds with one stone. It would allow implementations to > > save memory by discarding unused phase 1 info, but it would still allow them > > to send phase 2 deletes without renegotiating the phase 1. It would also > > allow applications to send host-referenced heartbeat packets in phase 1, > > which IMHO is the right place to send management-type packets. > > > > I know Dan said he would look into using using "inline Isakmp" messages to > > accomplish this, which is a form of pseudo-phase 1 SA as well; in order to > > send the message, you still have to keep a state. Instead, why not have the > > pseudo-phase 1 just store the encryption and authentication objects, plus > > the iv for info modes... I guess you'd need to track the phase 1 lifetime > > params as well. Plus the heartbeat info, of course. Anything else? Wouldn't > > this be easier (and less computationally intensive) than > > generating/verifying an RSA signature on every heartbeat? (and it wouldn't > > expose known-plaintext RSA sig pairs to a passive attacker) (P.S. I have to > > give Slava credit for this idea since I just noticed he proposed it already) > > > > The only other concern that I have heard about phase 1 heartbeats is that > > some people are worried that the IKE daemon may crash independently of the > > IPSEC task and they don't want a failure in IKE to cause the phase 2 SAs to > > go away. This may be an issue in load-sharing situations where the two > > processes may be running on different boxes. > > > > Jan suggested that the phase 1 heartbeat inform the peer which phase 2s are > > still up. I don't think this would be much of an issue if we had phase 1 > > heartbeats AND acknowledged info modes. (This also assumes that the IKE > > daemon 'knows' when a phase 2 goes down unpredictably.) > > > > I was thinking that probably we would want to use a periodic heartbeat > > message with a replay counter (i.e. a synchronous uni-directional > > heartbeat). Derrell commented that some vendors have already implemented a > > query-type heartbeat protocol. This seems less useful to me than a periodic > > uni-directional protocol. (How do you know when to query? If you wait until > > you need to send a packet then you have high latency. If you query on a > > regular basis then you get the same results as the synchronous protocol, but > > use twice the bandwidth.) > > > > Phase 2 Host-Referenced Heartbeats: > > > > This is an alternative to host-referenced heartbeats of the phase 1 variety. > > The advantage is that they do not rely on the existence of the phase 1 SA, > > so they are automatically compatible with dangling implementations. > > > > Still, they don't solve every possible scenerio. In the same way that a > > phase 1 heartbeat only tells you that the Isakmp daemon is running and not > > necessarily that the Ipsec layer is working, there is the possibility that > > one Ipsec SA may crash but another may continue working. In particular, I'm > > thinking of load-sharing scenarios where the tunnel endpoint is the same but > > the SAs are running on different host processors. > > > > I'm assuming that we would send them across a black-to-black tunnel. This > > would normally be used for management traffic, but Jan tells me that l2tp > > uses it as well. However, it would be easy to tell the l2tp traffic from the > > heartbeat traffic since the next protocol in the header would be l2tp, not > > icmp. > > > > Someone thought we should define a completely new protocol for ipsec > > heartbeats. This doesn't seem realistic to me. I suppose if ping was > > unacceptable we could define a new Isakmp message type and allow it to be > > interpreted as a heartbeat if it is received on an ipsec tunnel. But asking > > IANA for a new protocol number just for the heartbeats seems presumptuous. > > > > Jan also suggested the possibility of a new doi for heartbeat messages. That > > wouldn't be such a bad idea for host-referenced heartbeats. After all, they > > don't need to 'hijack' existing SAs, so there is no reason why they couldn't > > be negotiated within a completely separate domain. It might make this into a > > slightly bigger project than I intended, though. This also provides a > > potential fix for the load-sharing scenario. Since there is no requirement > > to > > > > There is also some potential for legacy support. If an existing host allows > > negotiation of black-to-black SAs and the SPD allows pings then the legacy > > host can be monitored for liveliness without any negotiation. I do think we > > need to support negotiation in the long run, though. > > > > A couple of people suggested sending a ping to the red (internal IP). I > > don't agree with this, since it would then require the peer to have > > knowledge of the internal IP, which is unnecessary (although I suppose the > > parameters for this could be negotiated). > > > > Phase 2 Sa-Referenced Heartbeats: > > > > A couple of people expressed interest in these, mostly as a > > resource-friendly alternative to host-referenced heartbeats. In remote > > access scenarios, typically there is only 1 (or only a few) phase 2 SA > > between the peers; adding a host-referenced heartbeat SA would double the > > resource requirements (assuming you are dropping the phase 1s). By hijacking > > an existing phase 2 you can save memory and negotiation time. > > > > I also foresaw two other uses: One was a simple solution to the load sharing > > scenario (sending the heartbeat on a hijacked SA guarantees that the same > > physical host that is sending the ping is the same one that is transmitting > > on the SA). The other possibility is that some phase 2 SAs (probably in the > > VPN backbone) will be deemed 'critical' (in that they guarantee less than > > 0.01% downtime or such). In order to ensure that these SAs are not only up, > > but also WORKING (i.e. the state on the peers is synchronized), it might be > > desirable to send a regular heartbeat message. > > > > Jan expressed concern that this would slow down Ipsec processing too much. > > That depends. How many people verify the source/dest addresses for the > > tunneled packet against the ones in the SPD? If you are already doing this > > for every packet then you lose no speed; if you just check the spi currently > > then adding the check for the IPs would slow you down. > > > > But I was thinking, maybe this is another case where using a separate doi > > would be useful. I wouldn't want to negotiate a separate SAs for the new doi > > (that would mostly defeat the point), but maybe a doi of IPSEC_MANAGEMENT > > could be used to identify management traffic that is flowing on an existing > > Ipsec SA. > > > > Jan expressed concern about not interfering with customer billing > > information, however all the proposed solutions have already taken this into > > account. Ditto with not allowing heartbeats to interfere with inactivity > > timers. > > > > Tero commented that phase 2 host-referenced heartbeats could be implemented > > as a special case of phase 2 sa-referenced heartbeats, which is what I > > originally intended. > > > > Heartbeat Negotiation Protocols: > > > > I didn't really bring this up before. I assume that we will need to have > > some kind of general negotiation framework in place (a subject that was > > discussed briefly and then dropped). In the meantime, I will probably label > > this an 'experimental future' and use a vendor id; however, since there will > > undoubtedly be parameters (e.g. heartbeat type, heartbeat frequency, > > recovery action, IP address to ping, etc.) regardless of which heartbeat > > format we decide on, maybe we will need a config exchange as well. > > > > Andrew > > _______________________________________________ > > Beauty without truth is insubstantial. > > Truth without beauty is unbearable. > > > > ------------------------------------------------------------------------ > > > > Subject: RE: Heartbeats (was RE: keepalives) > > Date: Fri, 3 Dec 1999 16:15:16 -0500 > > From: Andrew Krywaniuk > > To: ipsec@lists.tislabs.com > > > > How about, to get this discussion going, I suggest a format and you (the > > list) tell me if it seems appropriate. I can put this in a draft if there is > > interest in standardization. > > > > I think that different types of heartbeats (phase 1/phase 2, > > SA-referenced/host-referenced) provide different services, and we need to > > support all kinds. > > > > I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then > > search & replace with your favorite term. When I do refer to keep-alives at > > the end of the document, I use Tim's definition (a mechanism for disabling > > the peer's inactivity timeout). > > > > ---------------------------------------------------------------------------- > > > > As I see it, there are two types of heartbeats: phase 1 heartbeats and phase > > 2 heartbeats. > > > > PHASE 1 HEARTBEATS: > > > > Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they > > also tell you that the peer is still there. However, this is a sufficient > > but not necessary condition. The peer may be a dangling implementation, in > > which case they may not send phase 1 heartbeats even though they are still > > running. > > > > However, phase 1 heartbeats still have a use because they ensure that the > > peers will always agree on whether a phase 1 exists. It avoids the > > clumsiness of one peer trying to send a message on the phase 1, receiving > > NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase > > 1 is down and needs to be rekeyed. > > > > Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as > > a means of determining when an SA has gone down is vulnerable to DoS > > attacks, whereas heartbeats are not. > > > > I'm not going to discuss a format for phase 1 heartbeats in this post > > because IMHO it's not a technically difficult issue. Any one of a million > > packet formats would suffice (info mode, config mode, acknowledged info > > mode, some new exchange) and the only real issue is getting a group of > > people to settle on any particular one. > > > > PHASE 2 HEARTBEATS: > > > > There are two types of phase 2 heartbeats: host-referenced and > > SA-referenced. A host-referenced heartbeat is a protocol that runs across a > > dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a > > protocol that runs across an existing (user) SA. > > > > Host-referenced heartbeats can only be used to detect if the peer is still > > up and running. Therefore, they are of limited use. (However, the fact that > > they don't carry any sensitive information means that they they would never > > need to be deleted before their natural lifetime. Therefore, they would be > > the most reliable means of detecting if the peer is still alive since there > > is no possibility of a phase 2 delete being lost.) > > > > SA-referenced heartbeats detect if a specific phase 2 SA is still working. > > They also probably tell you when the peer is not there, since you wouldn't > > expect a phase 2 SA to disappear without receiving a delete (although I've > > been hearing some discussion of this recently on the list). However, they > > are probably the most useful type of heartbeat, which is why I am going to > > discuss them here. > > > > SA-referenced Phase 2 heartbeats are more technically complicated than other > > heartbeats because: > > > > 1) They must not interfere with the peer's inactivity timeouts. > > 2) They must not disturb any accounting services that may be running. > > 3) They must not result in any packets ending up on the peer's red network. > > 4) They must not assume that a phase 1 SA exists between the two peers. > > > > It is not, in general, possible to satisfy all of these constraints without > > some degree of cooperation. Therefore, both peers must be aware of the > > heartbeat scheme that is being used (i.e. it must be negotiated). > > > > In light of these constraints, I propose the following format: > > > > Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 > > and peer 2 replies. In order to distinguish these pings from user traffic, > > the source and destinations addresses are set to the hosts' black IPs. If > > either side fails to receive a heartbeat within N*X seconds then they can > > assume that the SA has gone down (and they should send a delete for it). (If > > they fail to receive a ping but they receive other traffic on the SA then > > something has gone wrong and they should log the event). Replay protection > > is not required, as IPSec automatically provides it. > > > > It is not necessary for peer 2 to ever initiate the pings. However, to > > increase reliability, if peer 2 does not receive a ping during the normal > > window [X, X*3/2], he may force the issue by initiating a ping in the > > opposite direction. > > > > This technique has the following advantages: > > > > 1) It satisfies all of the above constraints. > > 2) It does not require the host to have any knowledge of the peer's red IP > > or red subnet. > > 3) Ping has universal brand-name recognition as a heartbeat protocol. > > Therefore, no special payload format is required. > > > > and the following disadvantages: > > > > 1) The SPD must make a specific exception for ping packets between the black > > IPs. > > 2) The accounting service should know not to bill the user for this traffic. > > > > However, I believe these disadvantages will be inherent in any SA-referenced > > heartbeat scheme. > > > > Note that a Host-referenced heartbeat scheme could be constructed in the > > same way as an SA-referenced scheme, simply by negotiating a dedicated SA > > using the black IPs as the endpoints. This could be done in tunnel mode > > (presumably using the same policy exception that is used for SA-referenced > > heartbeats) or it could simply be done in transport mode. > > > > FUTURE CONSIDERATIONS: > > > > One potential limitation of this scheme is that it does not generalize well > > to keep-alives. The use of ping as a packet format is simple, but it doesn't > > allow us to specify any additional information (all it says is > > STILL_CONNECTED). It may be desirable to send extra information in the > > packet. For example, a simple keep-alive (in the literal sense) scheme would > > be to take the heartbeat scheme and add one extra bit of information (E.g. > > STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer > > that idle timeouts be disabled via. a negotiated attribute of the SA (if > > feature negotiation ever gets standardized). > > > > There is no particular reason to use ping as transport, except for the fact > > that it is already a universally accepted packet format and requires no > > approval from IANA. > > > > Andrew > > _______________________________________________ > > Beauty without truth is insubstantial. > > Truth without beauty is unbearable. > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 8 20:02:13 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02041; Wed, 8 Dec 1999 20:02:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07746 Wed, 8 Dec 1999 21:43:38 -0500 (EST) Date: Wed, 8 Dec 1999 21:46:24 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Heartbeats (was RE: keepalives) In-Reply-To: <384EDFCF.13D27FF4@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Michael C. Richardson" wrote: > I don't see any complexity, since you see the heartbeat coming out > of the descryption routines, and not even pass it to the routing engine. Unfortunately, this puts yet another special case right in the main path, the one that you want to optimize. In general, this is not a good thing. This sort of signalling really ought to use an out-of-band path. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Wed Dec 8 20:05:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02422; Wed, 8 Dec 1999 20:05:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07727 Wed, 8 Dec 1999 21:38:40 -0500 (EST) Message-ID: <384F15E2.9BC843C3@ire-ma.com> Date: Wed, 08 Dec 1999 21:37:27 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, If you talking about deleting _unexpired_ IKE SAs when there is a quiet period as far as heartbeats - and then you re-negotiate it when there is a need for a heartbeat - I see at least two problems with it: 1) possibility of re-negotiating IKE SAs more frequently than their expiration time - i.e. if IKE SA set to expire in 4 hours - you may end up re-negotiating it every hour (just a performance issue). 2) Often IKE SA re-negotiation means User interactive re-authentication (e.g. XAUTH/SecureID, and CRACK - where you can't re-key without re-authentication) - this also could be problematic. But if you talking about keeping IKE SA till it _expires_ and do not re-negotiate it until you need it again - I would agree with you. Jan Vilhuber wrote: > On Wed, 8 Dec 1999, Slava Kavsan wrote: > > Good summary Andrew! > > > > My vote goes to Phase1-based hearbeats using never-going-away IKE SAs > > I still disagree with this. It goes counter to what has been discussed > previously about continuous channel mode. I don't want to require anyone to > HAVE to keep their IKE SA up. Only when needed. > > The question I've seen is: Well, won't you need it all the time? > > Answer: No. In some cases, when you might have keepalives only with ipsec > traffic (for dial-up scnearios), you may have the link go quiet for extended > periods of time, during which you certainly do NOT need to keep the IKE SA > around. The normal negotiated lifetimes apply, and after that *poof* it goes > away (on both sides, I might add). When more ipsec traffic needs to be sent, > and new keepalives need to be sent, you renegotiate a phase 1. > > > (or > > skeletal ones for resource-restricted implementations - just enough to protect > > Informational messages). I would also like to suggest using Ack-ed NOTIFY > > mechanism and not to invent yet another scheme. Heartbeat management messages > > will also be useful. > > > I don't think we need to burden this scheme with more management messages. > All you need to do is to negotiate the kind of keepalive you want > (continuous, or only with ipsec traffic) and what frequency (if applicable), > and so on. After that, don't worry about it. > > Uni-directional heartbeats (to be negotiated by each side, i.e. each side > requests heartbeats to be sent from the other side) is acceptable, too, I > think, for the long run. I understand the argument about this cutting > messages down by half. As long as you can negotiate the frequency and the > type up front, I think this is acceptable (despite what some of us already > have implemented (in more than one way)). > > jan > > > Andrew Krywaniuk wrote: > > > > > Hi all. It's been a few days since my original post on this subject and > > > there have been a fair number of replies. Thanks to everyone who offered > > > comments. This message is a summary of all replies plus some comments from > > > me. > > > > > > I'm attaching the original message for context: < > > keepalives)>> > > > > > > Most people expressed an interest in host-referenced heartbeats. However, > > > they disagreed on what mechanism should be used to transport the heartbeats. > > > Some people preferred a phase 1 solution; others preferred a phase 2 > > > solution; a couple of people preferred clear pings. Only a couple of people > > > (Tero) agreed that it is desirable to support more than one kind of > > > heartbeat protocol. > > > > > > Clear Pings: > > > > > > I don't believe that clear pings are an acceptable solution. We can't > > > possibly prevent every kind of DoS attack, but we have an obligation to not > > > make them *easy*. > > > > > > Phase 1 Sa-Referenced Heartbeats: > > > > > > In the absence of phase 1 host-referenced heartbeats, these basically tell > > > you if the SA is still up. Since you have a reliable indication of when the > > > SA is up, an attacker can't induce you to renegotiate (a DoS threat) by > > > sending unauthenticated Notify Invalid Cookies (or spoofing a message with > > > invalid cookies). Also, it speeds up negotiation of phase 2s, since you know > > > ahead of time whether you need to negotiate a phase 1 first. No one showed > > > much interest in this type of heartbeat. > > > > > > Phase 1 Host-Referenced Heartbeats: > > > > > > The biggest problem with this idea is that phase 1 heartbeats seem to be > > > incompatible with dangling SA awareness. We have already established that > > > many vendors are not willing to use the continuous channel model, therefore > > > any phase 1 heartbeat scheme must be dangling SA aware. > > > > > > I know Jan has disputed this, but I think that most of us will want to send > > > heartbeat packets at regular intervals. If you set your heartbeat rate to > > > once every 30 seconds, how many people would want to renegotiate their phase > > > 1 at 30 second intervals (under low memory conditions)? > > > > > > On the other hand, I believe that we could get around this limitation by not > > > permitting dangling SAs, but allowing 'pseudo-dangling' SAs instead. In this > > > scenerio, implementations would not be permitted to delete their phase 1s at > > > will. However, they would be allowed to convert them into a skeletal form > > > (pseudo-phase 1), which contains just enough information to receive > > > heartbeats (and probably, by extension, info modes), but not enough to > > > negotiate QMs or use advanced features. > > > > > > This would kill two birds with one stone. It would allow implementations to > > > save memory by discarding unused phase 1 info, but it would still allow them > > > to send phase 2 deletes without renegotiating the phase 1. It would also > > > allow applications to send host-referenced heartbeat packets in phase 1, > > > which IMHO is the right place to send management-type packets. > > > > > > I know Dan said he would look into using using "inline Isakmp" messages to > > > accomplish this, which is a form of pseudo-phase 1 SA as well; in order to > > > send the message, you still have to keep a state. Instead, why not have the > > > pseudo-phase 1 just store the encryption and authentication objects, plus > > > the iv for info modes... I guess you'd need to track the phase 1 lifetime > > > params as well. Plus the heartbeat info, of course. Anything else? Wouldn't > > > this be easier (and less computationally intensive) than > > > generating/verifying an RSA signature on every heartbeat? (and it wouldn't > > > expose known-plaintext RSA sig pairs to a passive attacker) (P.S. I have to > > > give Slava credit for this idea since I just noticed he proposed it already) > > > > > > The only other concern that I have heard about phase 1 heartbeats is that > > > some people are worried that the IKE daemon may crash independently of the > > > IPSEC task and they don't want a failure in IKE to cause the phase 2 SAs to > > > go away. This may be an issue in load-sharing situations where the two > > > processes may be running on different boxes. > > > > > > Jan suggested that the phase 1 heartbeat inform the peer which phase 2s are > > > still up. I don't think this would be much of an issue if we had phase 1 > > > heartbeats AND acknowledged info modes. (This also assumes that the IKE > > > daemon 'knows' when a phase 2 goes down unpredictably.) > > > > > > I was thinking that probably we would want to use a periodic heartbeat > > > message with a replay counter (i.e. a synchronous uni-directional > > > heartbeat). Derrell commented that some vendors have already implemented a > > > query-type heartbeat protocol. This seems less useful to me than a periodic > > > uni-directional protocol. (How do you know when to query? If you wait until > > > you need to send a packet then you have high latency. If you query on a > > > regular basis then you get the same results as the synchronous protocol, but > > > use twice the bandwidth.) > > > > > > Phase 2 Host-Referenced Heartbeats: > > > > > > This is an alternative to host-referenced heartbeats of the phase 1 variety. > > > The advantage is that they do not rely on the existence of the phase 1 SA, > > > so they are automatically compatible with dangling implementations. > > > > > > Still, they don't solve every possible scenerio. In the same way that a > > > phase 1 heartbeat only tells you that the Isakmp daemon is running and not > > > necessarily that the Ipsec layer is working, there is the possibility that > > > one Ipsec SA may crash but another may continue working. In particular, I'm > > > thinking of load-sharing scenarios where the tunnel endpoint is the same but > > > the SAs are running on different host processors. > > > > > > I'm assuming that we would send them across a black-to-black tunnel. This > > > would normally be used for management traffic, but Jan tells me that l2tp > > > uses it as well. However, it would be easy to tell the l2tp traffic from the > > > heartbeat traffic since the next protocol in the header would be l2tp, not > > > icmp. > > > > > > Someone thought we should define a completely new protocol for ipsec > > > heartbeats. This doesn't seem realistic to me. I suppose if ping was > > > unacceptable we could define a new Isakmp message type and allow it to be > > > interpreted as a heartbeat if it is received on an ipsec tunnel. But asking > > > IANA for a new protocol number just for the heartbeats seems presumptuous. > > > > > > Jan also suggested the possibility of a new doi for heartbeat messages. That > > > wouldn't be such a bad idea for host-referenced heartbeats. After all, they > > > don't need to 'hijack' existing SAs, so there is no reason why they couldn't > > > be negotiated within a completely separate domain. It might make this into a > > > slightly bigger project than I intended, though. This also provides a > > > potential fix for the load-sharing scenario. Since there is no requirement > > > to > > > > > > There is also some potential for legacy support. If an existing host allows > > > negotiation of black-to-black SAs and the SPD allows pings then the legacy > > > host can be monitored for liveliness without any negotiation. I do think we > > > need to support negotiation in the long run, though. > > > > > > A couple of people suggested sending a ping to the red (internal IP). I > > > don't agree with this, since it would then require the peer to have > > > knowledge of the internal IP, which is unnecessary (although I suppose the > > > parameters for this could be negotiated). > > > > > > Phase 2 Sa-Referenced Heartbeats: > > > > > > A couple of people expressed interest in these, mostly as a > > > resource-friendly alternative to host-referenced heartbeats. In remote > > > access scenarios, typically there is only 1 (or only a few) phase 2 SA > > > between the peers; adding a host-referenced heartbeat SA would double the > > > resource requirements (assuming you are dropping the phase 1s). By hijacking > > > an existing phase 2 you can save memory and negotiation time. > > > > > > I also foresaw two other uses: One was a simple solution to the load sharing > > > scenario (sending the heartbeat on a hijacked SA guarantees that the same > > > physical host that is sending the ping is the same one that is transmitting > > > on the SA). The other possibility is that some phase 2 SAs (probably in the > > > VPN backbone) will be deemed 'critical' (in that they guarantee less than > > > 0.01% downtime or such). In order to ensure that these SAs are not only up, > > > but also WORKING (i.e. the state on the peers is synchronized), it might be > > > desirable to send a regular heartbeat message. > > > > > > Jan expressed concern that this would slow down Ipsec processing too much. > > > That depends. How many people verify the source/dest addresses for the > > > tunneled packet against the ones in the SPD? If you are already doing this > > > for every packet then you lose no speed; if you just check the spi currently > > > then adding the check for the IPs would slow you down. > > > > > > But I was thinking, maybe this is another case where using a separate doi > > > would be useful. I wouldn't want to negotiate a separate SAs for the new doi > > > (that would mostly defeat the point), but maybe a doi of IPSEC_MANAGEMENT > > > could be used to identify management traffic that is flowing on an existing > > > Ipsec SA. > > > > > > Jan expressed concern about not interfering with customer billing > > > information, however all the proposed solutions have already taken this into > > > account. Ditto with not allowing heartbeats to interfere with inactivity > > > timers. > > > > > > Tero commented that phase 2 host-referenced heartbeats could be implemented > > > as a special case of phase 2 sa-referenced heartbeats, which is what I > > > originally intended. > > > > > > Heartbeat Negotiation Protocols: > > > > > > I didn't really bring this up before. I assume that we will need to have > > > some kind of general negotiation framework in place (a subject that was > > > discussed briefly and then dropped). In the meantime, I will probably label > > > this an 'experimental future' and use a vendor id; however, since there will > > > undoubtedly be parameters (e.g. heartbeat type, heartbeat frequency, > > > recovery action, IP address to ping, etc.) regardless of which heartbeat > > > format we decide on, maybe we will need a config exchange as well. > > > > > > Andrew > > > _______________________________________________ > > > Beauty without truth is insubstantial. > > > Truth without beauty is unbearable. > > > > > > ------------------------------------------------------------------------ > > > > > > Subject: RE: Heartbeats (was RE: keepalives) > > > Date: Fri, 3 Dec 1999 16:15:16 -0500 > > > From: Andrew Krywaniuk > > > To: ipsec@lists.tislabs.com > > > > > > How about, to get this discussion going, I suggest a format and you (the > > > list) tell me if it seems appropriate. I can put this in a draft if there is > > > interest in standardization. > > > > > > I think that different types of heartbeats (phase 1/phase 2, > > > SA-referenced/host-referenced) provide different services, and we need to > > > support all kinds. > > > > > > I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then > > > search & replace with your favorite term. When I do refer to keep-alives at > > > the end of the document, I use Tim's definition (a mechanism for disabling > > > the peer's inactivity timeout). > > > > > > ---------------------------------------------------------------------------- > > > > > > As I see it, there are two types of heartbeats: phase 1 heartbeats and phase > > > 2 heartbeats. > > > > > > PHASE 1 HEARTBEATS: > > > > > > Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they > > > also tell you that the peer is still there. However, this is a sufficient > > > but not necessary condition. The peer may be a dangling implementation, in > > > which case they may not send phase 1 heartbeats even though they are still > > > running. > > > > > > However, phase 1 heartbeats still have a use because they ensure that the > > > peers will always agree on whether a phase 1 exists. It avoids the > > > clumsiness of one peer trying to send a message on the phase 1, receiving > > > NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase > > > 1 is down and needs to be rekeyed. > > > > > > Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as > > > a means of determining when an SA has gone down is vulnerable to DoS > > > attacks, whereas heartbeats are not. > > > > > > I'm not going to discuss a format for phase 1 heartbeats in this post > > > because IMHO it's not a technically difficult issue. Any one of a million > > > packet formats would suffice (info mode, config mode, acknowledged info > > > mode, some new exchange) and the only real issue is getting a group of > > > people to settle on any particular one. > > > > > > PHASE 2 HEARTBEATS: > > > > > > There are two types of phase 2 heartbeats: host-referenced and > > > SA-referenced. A host-referenced heartbeat is a protocol that runs across a > > > dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a > > > protocol that runs across an existing (user) SA. > > > > > > Host-referenced heartbeats can only be used to detect if the peer is still > > > up and running. Therefore, they are of limited use. (However, the fact that > > > they don't carry any sensitive information means that they they would never > > > need to be deleted before their natural lifetime. Therefore, they would be > > > the most reliable means of detecting if the peer is still alive since there > > > is no possibility of a phase 2 delete being lost.) > > > > > > SA-referenced heartbeats detect if a specific phase 2 SA is still working. > > > They also probably tell you when the peer is not there, since you wouldn't > > > expect a phase 2 SA to disappear without receiving a delete (although I've > > > been hearing some discussion of this recently on the list). However, they > > > are probably the most useful type of heartbeat, which is why I am going to > > > discuss them here. > > > > > > SA-referenced Phase 2 heartbeats are more technically complicated than other > > > heartbeats because: > > > > > > 1) They must not interfere with the peer's inactivity timeouts. > > > 2) They must not disturb any accounting services that may be running. > > > 3) They must not result in any packets ending up on the peer's red network. > > > 4) They must not assume that a phase 1 SA exists between the two peers. > > > > > > It is not, in general, possible to satisfy all of these constraints without > > > some degree of cooperation. Therefore, both peers must be aware of the > > > heartbeat scheme that is being used (i.e. it must be negotiated). > > > > > > In light of these constraints, I propose the following format: > > > > > > Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 > > > and peer 2 replies. In order to distinguish these pings from user traffic, > > > the source and destinations addresses are set to the hosts' black IPs. If > > > either side fails to receive a heartbeat within N*X seconds then they can > > > assume that the SA has gone down (and they should send a delete for it). (If > > > they fail to receive a ping but they receive other traffic on the SA then > > > something has gone wrong and they should log the event). Replay protection > > > is not required, as IPSec automatically provides it. > > > > > > It is not necessary for peer 2 to ever initiate the pings. However, to > > > increase reliability, if peer 2 does not receive a ping during the normal > > > window [X, X*3/2], he may force the issue by initiating a ping in the > > > opposite direction. > > > > > > This technique has the following advantages: > > > > > > 1) It satisfies all of the above constraints. > > > 2) It does not require the host to have any knowledge of the peer's red IP > > > or red subnet. > > > 3) Ping has universal brand-name recognition as a heartbeat protocol. > > > Therefore, no special payload format is required. > > > > > > and the following disadvantages: > > > > > > 1) The SPD must make a specific exception for ping packets between the black > > > IPs. > > > 2) The accounting service should know not to bill the user for this traffic. > > > > > > However, I believe these disadvantages will be inherent in any SA-referenced > > > heartbeat scheme. > > > > > > Note that a Host-referenced heartbeat scheme could be constructed in the > > > same way as an SA-referenced scheme, simply by negotiating a dedicated SA > > > using the black IPs as the endpoints. This could be done in tunnel mode > > > (presumably using the same policy exception that is used for SA-referenced > > > heartbeats) or it could simply be done in transport mode. > > > > > > FUTURE CONSIDERATIONS: > > > > > > One potential limitation of this scheme is that it does not generalize well > > > to keep-alives. The use of ping as a packet format is simple, but it doesn't > > > allow us to specify any additional information (all it says is > > > STILL_CONNECTED). It may be desirable to send extra information in the > > > packet. For example, a simple keep-alive (in the literal sense) scheme would > > > be to take the heartbeat scheme and add one extra bit of information (E.g. > > > STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer > > > that idle timeouts be disabled via. a negotiated attribute of the SA (if > > > feature negotiation ever gets standardized). > > > > > > There is no particular reason to use ping as transport, except for the fact > > > that it is already a universally accepted packet format and requires no > > > approval from IANA. > > > > > > Andrew > > > _______________________________________________ > > > Beauty without truth is insubstantial. > > > Truth without beauty is unbearable. > > > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 8 20:10:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02552; Wed, 8 Dec 1999 20:10:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07751 Wed, 8 Dec 1999 21:43:51 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 8 Dec 1999 18:47:03 -0800 (PST) From: Jan Vilhuber To: Slava Kavsan cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) In-Reply-To: <384F15E2.9BC843C3@ire-ma.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Dec 1999, Slava Kavsan wrote: > Jan, > > If you talking about deleting _unexpired_ IKE SAs when there is a quiet period as > far as heartbeats - and then you re-negotiate it when there is a need for a > heartbeat - I see at least two problems with it: > 1) possibility of re-negotiating IKE SAs more frequently than their expiration time > - i.e. if IKE SA set to expire in 4 hours - you may end up re-negotiating it every > hour (just a performance issue). > 2) Often IKE SA re-negotiation means User interactive re-authentication (e.g. > XAUTH/SecureID, and CRACK - where you can't re-key without re-authentication) - this > also could be problematic. > > But if you talking about keeping IKE SA till it _expires_ and do not re-negotiate it > until you need it again - I would agree with you. > You certainly can't (or rather: shouldn't) prevent people from deleting their unexpired IKE SA's, if they want to (and send you a delete notification, of course). The problem with xauth and crack is a real one, but either you keep state somehow (doubtful, since it's impossible, as far as I can tell), or you have to re-do it. But that's up to the implementor. Maybe in this case you simply can't delete unexpired SA's. Nothing says you can't, but when you do you might have to redo xauth. That's tough, but acceptable, in my opinion (i.e. not a protocol issue). jan > Jan Vilhuber wrote: > > > On Wed, 8 Dec 1999, Slava Kavsan wrote: > > > Good summary Andrew! > > > > > > My vote goes to Phase1-based hearbeats using never-going-away IKE SAs > > > > I still disagree with this. It goes counter to what has been discussed > > previously about continuous channel mode. I don't want to require anyone to > > HAVE to keep their IKE SA up. Only when needed. > > > > The question I've seen is: Well, won't you need it all the time? > > > > Answer: No. In some cases, when you might have keepalives only with ipsec > > traffic (for dial-up scnearios), you may have the link go quiet for extended > > periods of time, during which you certainly do NOT need to keep the IKE SA > > around. The normal negotiated lifetimes apply, and after that *poof* it goes > > away (on both sides, I might add). When more ipsec traffic needs to be sent, > > and new keepalives need to be sent, you renegotiate a phase 1. > > > > > (or > > > skeletal ones for resource-restricted implementations - just enough to protect > > > Informational messages). I would also like to suggest using Ack-ed NOTIFY > > > mechanism and not to invent yet another scheme. Heartbeat management messages > > > will also be useful. > > > > > I don't think we need to burden this scheme with more management messages. > > All you need to do is to negotiate the kind of keepalive you want > > (continuous, or only with ipsec traffic) and what frequency (if applicable), > > and so on. After that, don't worry about it. > > > > Uni-directional heartbeats (to be negotiated by each side, i.e. each side > > requests heartbeats to be sent from the other side) is acceptable, too, I > > think, for the long run. I understand the argument about this cutting > > messages down by half. As long as you can negotiate the frequency and the > > type up front, I think this is acceptable (despite what some of us already > > have implemented (in more than one way)). > > > > jan > > > > > Andrew Krywaniuk wrote: > > > > > > > Hi all. It's been a few days since my original post on this subject and > > > > there have been a fair number of replies. Thanks to everyone who offered > > > > comments. This message is a summary of all replies plus some comments from > > > > me. > > > > > > > > I'm attaching the original message for context: < > > > keepalives)>> > > > > > > > > Most people expressed an interest in host-referenced heartbeats. However, > > > > they disagreed on what mechanism should be used to transport the heartbeats. > > > > Some people preferred a phase 1 solution; others preferred a phase 2 > > > > solution; a couple of people preferred clear pings. Only a couple of people > > > > (Tero) agreed that it is desirable to support more than one kind of > > > > heartbeat protocol. > > > > > > > > Clear Pings: > > > > > > > > I don't believe that clear pings are an acceptable solution. We can't > > > > possibly prevent every kind of DoS attack, but we have an obligation to not > > > > make them *easy*. > > > > > > > > Phase 1 Sa-Referenced Heartbeats: > > > > > > > > In the absence of phase 1 host-referenced heartbeats, these basically tell > > > > you if the SA is still up. Since you have a reliable indication of when the > > > > SA is up, an attacker can't induce you to renegotiate (a DoS threat) by > > > > sending unauthenticated Notify Invalid Cookies (or spoofing a message with > > > > invalid cookies). Also, it speeds up negotiation of phase 2s, since you know > > > > ahead of time whether you need to negotiate a phase 1 first. No one showed > > > > much interest in this type of heartbeat. > > > > > > > > Phase 1 Host-Referenced Heartbeats: > > > > > > > > The biggest problem with this idea is that phase 1 heartbeats seem to be > > > > incompatible with dangling SA awareness. We have already established that > > > > many vendors are not willing to use the continuous channel model, therefore > > > > any phase 1 heartbeat scheme must be dangling SA aware. > > > > > > > > I know Jan has disputed this, but I think that most of us will want to send > > > > heartbeat packets at regular intervals. If you set your heartbeat rate to > > > > once every 30 seconds, how many people would want to renegotiate their phase > > > > 1 at 30 second intervals (under low memory conditions)? > > > > > > > > On the other hand, I believe that we could get around this limitation by not > > > > permitting dangling SAs, but allowing 'pseudo-dangling' SAs instead. In this > > > > scenerio, implementations would not be permitted to delete their phase 1s at > > > > will. However, they would be allowed to convert them into a skeletal form > > > > (pseudo-phase 1), which contains just enough information to receive > > > > heartbeats (and probably, by extension, info modes), but not enough to > > > > negotiate QMs or use advanced features. > > > > > > > > This would kill two birds with one stone. It would allow implementations to > > > > save memory by discarding unused phase 1 info, but it would still allow them > > > > to send phase 2 deletes without renegotiating the phase 1. It would also > > > > allow applications to send host-referenced heartbeat packets in phase 1, > > > > which IMHO is the right place to send management-type packets. > > > > > > > > I know Dan said he would look into using using "inline Isakmp" messages to > > > > accomplish this, which is a form of pseudo-phase 1 SA as well; in order to > > > > send the message, you still have to keep a state. Instead, why not have the > > > > pseudo-phase 1 just store the encryption and authentication objects, plus > > > > the iv for info modes... I guess you'd need to track the phase 1 lifetime > > > > params as well. Plus the heartbeat info, of course. Anything else? Wouldn't > > > > this be easier (and less computationally intensive) than > > > > generating/verifying an RSA signature on every heartbeat? (and it wouldn't > > > > expose known-plaintext RSA sig pairs to a passive attacker) (P.S. I have to > > > > give Slava credit for this idea since I just noticed he proposed it already) > > > > > > > > The only other concern that I have heard about phase 1 heartbeats is that > > > > some people are worried that the IKE daemon may crash independently of the > > > > IPSEC task and they don't want a failure in IKE to cause the phase 2 SAs to > > > > go away. This may be an issue in load-sharing situations where the two > > > > processes may be running on different boxes. > > > > > > > > Jan suggested that the phase 1 heartbeat inform the peer which phase 2s are > > > > still up. I don't think this would be much of an issue if we had phase 1 > > > > heartbeats AND acknowledged info modes. (This also assumes that the IKE > > > > daemon 'knows' when a phase 2 goes down unpredictably.) > > > > > > > > I was thinking that probably we would want to use a periodic heartbeat > > > > message with a replay counter (i.e. a synchronous uni-directional > > > > heartbeat). Derrell commented that some vendors have already implemented a > > > > query-type heartbeat protocol. This seems less useful to me than a periodic > > > > uni-directional protocol. (How do you know when to query? If you wait until > > > > you need to send a packet then you have high latency. If you query on a > > > > regular basis then you get the same results as the synchronous protocol, but > > > > use twice the bandwidth.) > > > > > > > > Phase 2 Host-Referenced Heartbeats: > > > > > > > > This is an alternative to host-referenced heartbeats of the phase 1 variety. > > > > The advantage is that they do not rely on the existence of the phase 1 SA, > > > > so they are automatically compatible with dangling implementations. > > > > > > > > Still, they don't solve every possible scenerio. In the same way that a > > > > phase 1 heartbeat only tells you that the Isakmp daemon is running and not > > > > necessarily that the Ipsec layer is working, there is the possibility that > > > > one Ipsec SA may crash but another may continue working. In particular, I'm > > > > thinking of load-sharing scenarios where the tunnel endpoint is the same but > > > > the SAs are running on different host processors. > > > > > > > > I'm assuming that we would send them across a black-to-black tunnel. This > > > > would normally be used for management traffic, but Jan tells me that l2tp > > > > uses it as well. However, it would be easy to tell the l2tp traffic from the > > > > heartbeat traffic since the next protocol in the header would be l2tp, not > > > > icmp. > > > > > > > > Someone thought we should define a completely new protocol for ipsec > > > > heartbeats. This doesn't seem realistic to me. I suppose if ping was > > > > unacceptable we could define a new Isakmp message type and allow it to be > > > > interpreted as a heartbeat if it is received on an ipsec tunnel. But asking > > > > IANA for a new protocol number just for the heartbeats seems presumptuous. > > > > > > > > Jan also suggested the possibility of a new doi for heartbeat messages. That > > > > wouldn't be such a bad idea for host-referenced heartbeats. After all, they > > > > don't need to 'hijack' existing SAs, so there is no reason why they couldn't > > > > be negotiated within a completely separate domain. It might make this into a > > > > slightly bigger project than I intended, though. This also provides a > > > > potential fix for the load-sharing scenario. Since there is no requirement > > > > to > > > > > > > > There is also some potential for legacy support. If an existing host allows > > > > negotiation of black-to-black SAs and the SPD allows pings then the legacy > > > > host can be monitored for liveliness without any negotiation. I do think we > > > > need to support negotiation in the long run, though. > > > > > > > > A couple of people suggested sending a ping to the red (internal IP). I > > > > don't agree with this, since it would then require the peer to have > > > > knowledge of the internal IP, which is unnecessary (although I suppose the > > > > parameters for this could be negotiated). > > > > > > > > Phase 2 Sa-Referenced Heartbeats: > > > > > > > > A couple of people expressed interest in these, mostly as a > > > > resource-friendly alternative to host-referenced heartbeats. In remote > > > > access scenarios, typically there is only 1 (or only a few) phase 2 SA > > > > between the peers; adding a host-referenced heartbeat SA would double the > > > > resource requirements (assuming you are dropping the phase 1s). By hijacking > > > > an existing phase 2 you can save memory and negotiation time. > > > > > > > > I also foresaw two other uses: One was a simple solution to the load sharing > > > > scenario (sending the heartbeat on a hijacked SA guarantees that the same > > > > physical host that is sending the ping is the same one that is transmitting > > > > on the SA). The other possibility is that some phase 2 SAs (probably in the > > > > VPN backbone) will be deemed 'critical' (in that they guarantee less than > > > > 0.01% downtime or such). In order to ensure that these SAs are not only up, > > > > but also WORKING (i.e. the state on the peers is synchronized), it might be > > > > desirable to send a regular heartbeat message. > > > > > > > > Jan expressed concern that this would slow down Ipsec processing too much. > > > > That depends. How many people verify the source/dest addresses for the > > > > tunneled packet against the ones in the SPD? If you are already doing this > > > > for every packet then you lose no speed; if you just check the spi currently > > > > then adding the check for the IPs would slow you down. > > > > > > > > But I was thinking, maybe this is another case where using a separate doi > > > > would be useful. I wouldn't want to negotiate a separate SAs for the new doi > > > > (that would mostly defeat the point), but maybe a doi of IPSEC_MANAGEMENT > > > > could be used to identify management traffic that is flowing on an existing > > > > Ipsec SA. > > > > > > > > Jan expressed concern about not interfering with customer billing > > > > information, however all the proposed solutions have already taken this into > > > > account. Ditto with not allowing heartbeats to interfere with inactivity > > > > timers. > > > > > > > > Tero commented that phase 2 host-referenced heartbeats could be implemented > > > > as a special case of phase 2 sa-referenced heartbeats, which is what I > > > > originally intended. > > > > > > > > Heartbeat Negotiation Protocols: > > > > > > > > I didn't really bring this up before. I assume that we will need to have > > > > some kind of general negotiation framework in place (a subject that was > > > > discussed briefly and then dropped). In the meantime, I will probably label > > > > this an 'experimental future' and use a vendor id; however, since there will > > > > undoubtedly be parameters (e.g. heartbeat type, heartbeat frequency, > > > > recovery action, IP address to ping, etc.) regardless of which heartbeat > > > > format we decide on, maybe we will need a config exchange as well. > > > > > > > > Andrew > > > > _______________________________________________ > > > > Beauty without truth is insubstantial. > > > > Truth without beauty is unbearable. > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > Subject: RE: Heartbeats (was RE: keepalives) > > > > Date: Fri, 3 Dec 1999 16:15:16 -0500 > > > > From: Andrew Krywaniuk > > > > To: ipsec@lists.tislabs.com > > > > > > > > How about, to get this discussion going, I suggest a format and you (the > > > > list) tell me if it seems appropriate. I can put this in a draft if there is > > > > interest in standardization. > > > > > > > > I think that different types of heartbeats (phase 1/phase 2, > > > > SA-referenced/host-referenced) provide different services, and we need to > > > > support all kinds. > > > > > > > > I use the term 'heartbeat' throughout. If you prefer keep-alive, etc. then > > > > search & replace with your favorite term. When I do refer to keep-alives at > > > > the end of the document, I use Tim's definition (a mechanism for disabling > > > > the peer's inactivity timeout). > > > > > > > > ---------------------------------------------------------------------------- > > > > > > > > As I see it, there are two types of heartbeats: phase 1 heartbeats and phase > > > > 2 heartbeats. > > > > > > > > PHASE 1 HEARTBEATS: > > > > > > > > Phase 1 heartbeats tell you if the phase 1 SA is still up. Therefore, they > > > > also tell you that the peer is still there. However, this is a sufficient > > > > but not necessary condition. The peer may be a dangling implementation, in > > > > which case they may not send phase 1 heartbeats even though they are still > > > > running. > > > > > > > > However, phase 1 heartbeats still have a use because they ensure that the > > > > peers will always agree on whether a phase 1 exists. It avoids the > > > > clumsiness of one peer trying to send a message on the phase 1, receiving > > > > NOTIFY_INVALID_COOKIES and then timing out, before realizing that the phase > > > > 1 is down and needs to be rekeyed. > > > > > > > > Also, as was discussed in an earlier thread, using NOTIFY_INVALID_COOKIES as > > > > a means of determining when an SA has gone down is vulnerable to DoS > > > > attacks, whereas heartbeats are not. > > > > > > > > I'm not going to discuss a format for phase 1 heartbeats in this post > > > > because IMHO it's not a technically difficult issue. Any one of a million > > > > packet formats would suffice (info mode, config mode, acknowledged info > > > > mode, some new exchange) and the only real issue is getting a group of > > > > people to settle on any particular one. > > > > > > > > PHASE 2 HEARTBEATS: > > > > > > > > There are two types of phase 2 heartbeats: host-referenced and > > > > SA-referenced. A host-referenced heartbeat is a protocol that runs across a > > > > dedicated phase 2 SA between the two peers. An SA-referenced heartbeat is a > > > > protocol that runs across an existing (user) SA. > > > > > > > > Host-referenced heartbeats can only be used to detect if the peer is still > > > > up and running. Therefore, they are of limited use. (However, the fact that > > > > they don't carry any sensitive information means that they they would never > > > > need to be deleted before their natural lifetime. Therefore, they would be > > > > the most reliable means of detecting if the peer is still alive since there > > > > is no possibility of a phase 2 delete being lost.) > > > > > > > > SA-referenced heartbeats detect if a specific phase 2 SA is still working. > > > > They also probably tell you when the peer is not there, since you wouldn't > > > > expect a phase 2 SA to disappear without receiving a delete (although I've > > > > been hearing some discussion of this recently on the list). However, they > > > > are probably the most useful type of heartbeat, which is why I am going to > > > > discuss them here. > > > > > > > > SA-referenced Phase 2 heartbeats are more technically complicated than other > > > > heartbeats because: > > > > > > > > 1) They must not interfere with the peer's inactivity timeouts. > > > > 2) They must not disturb any accounting services that may be running. > > > > 3) They must not result in any packets ending up on the peer's red network. > > > > 4) They must not assume that a phase 1 SA exists between the two peers. > > > > > > > > It is not, in general, possible to satisfy all of these constraints without > > > > some degree of cooperation. Therefore, both peers must be aware of the > > > > heartbeat scheme that is being used (i.e. it must be negotiated). > > > > > > > > In light of these constraints, I propose the following format: > > > > > > > > Every X seconds, peer 1 (the initiator) sends an encrypted ping to peer 2 > > > > and peer 2 replies. In order to distinguish these pings from user traffic, > > > > the source and destinations addresses are set to the hosts' black IPs. If > > > > either side fails to receive a heartbeat within N*X seconds then they can > > > > assume that the SA has gone down (and they should send a delete for it). (If > > > > they fail to receive a ping but they receive other traffic on the SA then > > > > something has gone wrong and they should log the event). Replay protection > > > > is not required, as IPSec automatically provides it. > > > > > > > > It is not necessary for peer 2 to ever initiate the pings. However, to > > > > increase reliability, if peer 2 does not receive a ping during the normal > > > > window [X, X*3/2], he may force the issue by initiating a ping in the > > > > opposite direction. > > > > > > > > This technique has the following advantages: > > > > > > > > 1) It satisfies all of the above constraints. > > > > 2) It does not require the host to have any knowledge of the peer's red IP > > > > or red subnet. > > > > 3) Ping has universal brand-name recognition as a heartbeat protocol. > > > > Therefore, no special payload format is required. > > > > > > > > and the following disadvantages: > > > > > > > > 1) The SPD must make a specific exception for ping packets between the black > > > > IPs. > > > > 2) The accounting service should know not to bill the user for this traffic. > > > > > > > > However, I believe these disadvantages will be inherent in any SA-referenced > > > > heartbeat scheme. > > > > > > > > Note that a Host-referenced heartbeat scheme could be constructed in the > > > > same way as an SA-referenced scheme, simply by negotiating a dedicated SA > > > > using the black IPs as the endpoints. This could be done in tunnel mode > > > > (presumably using the same policy exception that is used for SA-referenced > > > > heartbeats) or it could simply be done in transport mode. > > > > > > > > FUTURE CONSIDERATIONS: > > > > > > > > One potential limitation of this scheme is that it does not generalize well > > > > to keep-alives. The use of ping as a packet format is simple, but it doesn't > > > > allow us to specify any additional information (all it says is > > > > STILL_CONNECTED). It may be desirable to send extra information in the > > > > packet. For example, a simple keep-alive (in the literal sense) scheme would > > > > be to take the heartbeat scheme and add one extra bit of information (E.g. > > > > STILL_CONNECTED, IDLE_TIMEOUT=disabled). On the other hand, I would prefer > > > > that idle timeouts be disabled via. a negotiated attribute of the SA (if > > > > feature negotiation ever gets standardized). > > > > > > > > There is no particular reason to use ping as transport, except for the fact > > > > that it is already a universally accepted packet format and requires no > > > > approval from IANA. > > > > > > > > Andrew > > > > _______________________________________________ > > > > Beauty without truth is insubstantial. > > > > Truth without beauty is unbearable. > > > > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Dec 8 20:39:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA06122; Wed, 8 Dec 1999 20:39:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA07841 Wed, 8 Dec 1999 22:25:54 -0500 (EST) Message-Id: <199912090327.WAA03222@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-reply-to: Your message of "Wed, 08 Dec 1999 20:23:29 EST." <384F0490.1FA838FA@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Dec 1999 22:27:41 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> "Michael C. Richardson" wrote: >> My opinion is that clients don't do heartbeats, since they don't have >> 2000 SAs that they want to track. Slava> To prevent Clients from detecting dead Gateways or other host - is Slava> very restricting in my opinion - for example, it will prevent Slava> Client to re-engage with redundant gateways. Heartbeats have be Slava> available to any IPSec host that wants to use them. It seems to me, that the fact that a client is receiving traffic from the gateway is enough to permit the client to determine that the gateway is alive. That may not be enough for high-availability: really it should worry about whether the server which it wants to contact is available. The client could easily ping *that* box instead. No additional SA required. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Dec 8 22:53:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12376; Wed, 8 Dec 1999 22:53:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08185 Thu, 9 Dec 1999 00:33:52 -0500 (EST) Date: Thu, 9 Dec 1999 07:37:28 +0200 (EET) Message-Id: <199912090537.HAA16730@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Slava Kavsan Cc: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) In-Reply-To: <384F0B1F.7F005895@ire-ma.com> References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> <384F0B1F.7F005895@ire-ma.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 63 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Slava Kavsan writes: > My vote goes to Phase1-based hearbeats using never-going-away IKE > SAs (or skeletal ones for resource-restricted implementations - just > enough to protect Informational messages). I don't think people want to implement "skeletal IKE SAs". More code, more special cases, uncommon code path == untested code == lots of bugs... BTW, I am not really happy having the IKE SA to transfer more and more data. Currently the IKE can happily be in user mode and use software encryption, because the amount of data to be transferred is that small. If we start sending hearbeats inside the IKE message we also might end up consuming our randomness quite fast. For each IKE message we need to create random message id and a random nonce. > I would also like to suggest using Ack-ed NOTIFY mechanism and not > to invent yet another scheme. Heartbeat management messages will > also be useful. If we really want to have phase 1 heartbeat, I think one way notify from both ends using negotiated interval is the right way to do. Anyways I think phase 2 heartbeats are the ones we want to move forward, and preferredly we are using just normal ping packets to the some ip-address of the other end. I.e during the Phase 2 SA negotiation, the initiator or responder will send REQUEST_HEARTBEATS notify, which contains ip-number and interval to use inside the notification data field (as data attribute list). The other one will then start sending those packets using that SA just negotiated. The ip address must be from the range that is covered by the quick mode selectors. Either end can enable it, and the other end will acknowledge the willingness of doing it by starting to send heartbeats packets. The requestor can see if the other end is up and running by watching for those ping packets, and it will reply to them in normal way. If it never sees any ping packets it must assume that the other end does not support heartbeats, and disable the feature. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 9 01:36:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20192; Thu, 9 Dec 1999 01:36:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA08581 Thu, 9 Dec 1999 03:00:53 -0500 (EST) Message-ID: <384F618B.238B553C@ire-ma.com> Date: Thu, 09 Dec 1999 03:00:12 -0500 From: Slava Kavsan X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> <384F0B1F.7F005895@ire-ma.com> <199912090537.HAA16730@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > The other one will then start sending those packets using that SA just > negotiated. The ip address must be from the range that is covered by > the quick mode selectors. Tero, Interesting idea. Question: how do you send ICMP heartbeats on IPSec SAs that are restricted to TCP-only or UDP-only protocols? From owner-ipsec@lists.tislabs.com Thu Dec 9 02:37:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20961; Thu, 9 Dec 1999 02:37:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA08777 Thu, 9 Dec 1999 03:56:53 -0500 (EST) Message-ID: <00ab01bf4223$1fba39d0$3e4fa8c0@iaf.fi> From: "Sami Vaarala" To: Cc: "Kanta Matsuura" , "Bronislav Kavsan" References: <9912090136.AA02785@Ichiko.imailab.iis.u-tokyo.ac.jp> Subject: Re: cookie verification Date: Thu, 9 Dec 1999 10:55:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kanta, > Hi, > The use of IKE Cookie in a draft > http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt > is better in terms of statelessness. Indeed it is: the first message does not require a responder to store state. An approach similar to this one (with regards to re-sending the data in the first message later) could work for other IKE modes as well, without making the exchanges longer. I wonder if this could be done easily using a "standard transform" to a given stateful mode? As an aside, how do you prevent an attacker from doing a "cookie jar" attack? A malicious initiator can initiate new exchanges by sending the first message and receiving the second message of each exchange, and then calculate the appropriate third messages corresponding to each new exchange -- without sending them immediately. After collecting eg 1000 valid responses, he can send them all at once to swamp the responder. Admittedly, the attacker will have to do a roughly equal amount of work, but over a longer period of time (and thus he will not be swamped). The responder can not know how old each of the messages are, so he will accept them. (The local secret for cookie generation can, of course, be changed once in a while, but that interval may be long enough to pull the attack off?) If the responder cookie in the draft included time, the responder could roughly estimate the age of the cookie (and thus the exchange) upon receiving the third message, and refuse to participate if the cookie is older than eg 15 seconds. As I said earlier, our cookie generation method allows us to determine the age of the cookie with quite a good resolution. If applied to this draft, upon receiving the third message the responder would verify the cookie and determine its age (eg resolution of a second). It would then ignore the message if it was older than what we're willing to accept. If you'd be interested I could document the cookie generation method we're using -- perhaps this would be useful for your draft? Sami -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Thu Dec 9 03:30:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23789; Thu, 9 Dec 1999 03:30:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA08904 Thu, 9 Dec 1999 04:53:56 -0500 (EST) Message-Id: <9912091010.AA02801@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Thu, 09 Dec 1999 19:10:15 +0900 To: "Sami Vaarala" Cc: , "Kanta Matsuura" , "Bronislav Kavsan" Subject: Re: cookie verification In-Reply-To: <00ab01bf4223$1fba39d0$3e4fa8c0@iaf.fi> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sami, Thank you for the reply. "Sami Vaarala" wrote: >>> Hi, >>> The use of IKE Cookie in a draft >>> http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt >>> is better in terms of statelessness. >> >>Indeed it is: the first message does not require a responder >>to store state. An approach similar to this one (with >>regards to re-sending the data in the first message later) >>could work for other IKE modes as well, without making the >>exchanges longer. I wonder if this could be done easily >>using a "standard transform" to a given stateful mode? I'm not quite sure what do you mean by "standard transform". >>As an aside, how do you prevent an attacker from doing a >>"cookie jar" attack? A malicious initiator can initiate >>new exchanges by sending the first message and receiving >>the second message of each exchange, and then calculate >>the appropriate third messages corresponding to each new >>exchange -- without sending them immediately. After >>collecting eg 1000 valid responses, he can send them all >>at once to swamp the responder. >> >>Admittedly, the attacker will have to do a roughly equal >>amount of work, but over a longer period of time (and thus >>he will not be swamped). The responder can not know how >>old each of the messages are, so he will accept them. >>(The local secret for cookie generation can, of course, >>be changed once in a while, but that interval may be >>long enough to pull the attack off?) Of course, in terms of connection timeout, there exists a trade-off between performance (for an innocent entity who couldn't make a quick response due to some unfortunate conditions) and DoS-resistance. If we use the signature mode in my draft, the amount of attacker's work includes heavy signature verification. This makes the trade-off better. >>If the responder cookie in the draft included time, the >>responder could roughly estimate the age of the cookie >>(and thus the exchange) upon receiving the third message, >>and refuse to participate if the cookie is older than eg >>15 seconds. >>As I said earlier, our cookie generation method allows us >>to determine the age of the cookie with quite a good >>resolution. If applied to this draft, upon receiving the >>third message the responder would verify the cookie and >>determine its age (eg resolution of a second). It would >>then ignore the message if it was older than what we're >>willing to accept. This could be useful for making a specific evaluation by using performance specification of the currently-available implementation of public-key primitives; we could find an appropriate period for timeout. >>If you'd be interested I could document the cookie generation >>method we're using -- perhaps this would be useful for your >>draft? Yes, I'm interested in it. Please go ahead! --^^-- Kanta From owner-ipsec@lists.tislabs.com Thu Dec 9 05:34:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25132; Thu, 9 Dec 1999 05:34:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09107 Thu, 9 Dec 1999 07:01:44 -0500 (EST) Message-Id: <199912091204.PAA07910@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: , "Sami Vaarala" Date: Thu, 9 Dec 1999 15:03:53 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: cookie verification CC: "Kanta Matsuura" , "Bronislav Kavsan" In-reply-to: <00ab01bf4223$1fba39d0$3e4fa8c0@iaf.fi> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 9 Dec 99, at 10:55, Sami Vaarala wrote: Sami, > Kanta, > > > Hi, > > The use of IKE Cookie in a draft > > http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt > > is better in terms of statelessness. > > Indeed it is: the first message does not require a responder > to store state. An approach similar to this one (with > regards to re-sending the data in the first message later) > could work for other IKE modes as well, without making the > exchanges longer. I wonder if this could be done easily > using a "standard transform" to a given stateful mode? I thought about this also. Resending the data in the first message later has its disadvantages when the amount of data is big enough. And it is the first IKE packet where this often may be true - unlike the other IKE packets, which size is limited (unless you send a lot of certs or VendorID payloads), the first packet may contain SA with hundreds of proposals. Resending such amound of data only for anti- clogging purposes seems not to be a reasonable. Perhaps adding one more roundtrip of pure cookie exchange would be better. But, unfortunately, in any case it requires modification of IKE. > As an aside, how do you prevent an attacker from doing a > "cookie jar" attack? A malicious initiator can initiate > new exchanges by sending the first message and receiving > the second message of each exchange, and then calculate > the appropriate third messages corresponding to each new > exchange -- without sending them immediately. After > collecting eg 1000 valid responses, he can send them all > at once to swamp the responder. > > Admittedly, the attacker will have to do a roughly equal > amount of work, but over a longer period of time (and thus > he will not be swamped). The responder can not know how > old each of the messages are, so he will accept them. > (The local secret for cookie generation can, of course, > be changed once in a while, but that interval may be > long enough to pull the attack off?) I guess, in this case you need to change local secret with an interval equal to one you agree to accept your cookie within (more precisely, you need to change it twice more frequently and keep two last secrets and try both). > If the responder cookie in the draft included time, the > responder could roughly estimate the age of the cookie > (and thus the exchange) upon receiving the third message, > and refuse to participate if the cookie is older than eg > 15 seconds. > > As I said earlier, our cookie generation method allows us > to determine the age of the cookie with quite a good > resolution. If applied to this draft, upon receiving the > third message the responder would verify the cookie and > determine its age (eg resolution of a second). It would > then ignore the message if it was older than what we're > willing to accept. > > If you'd be interested I could document the cookie generation > method we're using -- perhaps this would be useful for your > draft? Please, do it. I think it would be useful anyway. > Sami > > -- > Sami Vaarala (sami.vaarala@netseal.com) > NetSeal Technologies > http://www.netseal.com/ Regards, Valera Smyslov. From owner-ipsec@lists.tislabs.com Thu Dec 9 05:36:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25160; Thu, 9 Dec 1999 05:36:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09087 Thu, 9 Dec 1999 06:55:49 -0500 (EST) Message-Id: <199912091158.GAA22576@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-ecn-02.txt Date: Thu, 09 Dec 1999 06:58:10 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IPsec Interactions with ECN Author(s) : S. Floyd, D. Black, K. Ramakrishnan Filename : draft-ietf-ipsec-ecn-02.txt Pages : 24 Date : 08-Dec-99 IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode. Explicit Congestion Notification (ECN) is an experimental addition to the IP architecture that provides notification of onset of congestion to delay- or loss- sensitive applications. ECN provides congestion notifications to enable adaptation to network conditions without the impact of dropped packets [RFC 2481]. The use of two bits in the IPsec header for ECN experimentation conflicts with header processing at IPsec tunnel endpoints in a manner that makes ECN unusable in the presence of IPsec tunnels. This document considers issues related to this conflict, describes two alternative solutions, and updates the IPsec architecture [RFC 2401] to include these alternatives. Support for one or the other of these alternatives is REQUIRED to remove the underlying conflict. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ecn-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ecn-02.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-ecn-02.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: <19991208145714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ecn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ecn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991208145714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Dec 9 05:44:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25278; Thu, 9 Dec 1999 05:44:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09136 Thu, 9 Dec 1999 07:17:35 -0500 (EST) Message-ID: <3C3175FCC945D211B65100805F1580890A487530@RED-MSG-07> From: William Dixon To: "'ipsec@lists.tislabs.com'" Subject: Windows 2000 IPSec interop web site Date: Thu, 9 Dec 1999 04:20:40 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IPSec team at Microsoft has established an Internet web site for IPSec interop testing against Windows 2000 server, both IPSec AH & ESP, AH+ESP, transport and tunnel mode with DES, 3DES, MD5 and SHA1 combinations, at http://w2kipsec-pub.rte.microsoft.com, address 131.107.152.30. Full instructions are on the web page, which is clear text accessible. Multiple users can test simultaneously. The test machine is otherwise unprotected, with a web server, ftp server running. We are already getting random hack attempts periodically on the site (just because it's there?), so send mail to ipsecpki@microsoft.com if you can't reach it or the Microsoft CA test site, http://sectestca1.rte.microsoft.com >From inside out ------------- Win2000 client (10.10.10.2) | | (10.10.10.1) Win2000 Server 131.107.152.29) = = Internet = (your Internet IP) your gateway (your internal IP) | | (client internal IP) your client The .30 and .29 addresses are pingable to allow you to see if it is reachable (assuming you didn't block this to your IP address with policy). Please have someone on your product team try this out and let us know if you have successfully tested against it or have problems. Report issues to: ipsecpki@microsoft.com. We will reply as soon as we can, but there may be some delay. This is not a Win2000 VPN server, so don't expect L2TP or PPTP support, just IPSec transport and tunnel support that you configure yourself through the web page. If you are using Windows 2000 on your side, you may wish to enable IPSec auditing for Logon/Logoff events in the Audit Policy on the local machine. To enable Oakley.log negotiation tracing for debugging: 1. create a key called Oakley under HKLM\System\CurrentControlSet\Services\PolicyAgent 2. add value, Reg_DWORD, name EnableLogging, value=1 The file will be written to %windir%\debug\oakley.log and oakley.log.sav (the previous log after service is restarted) Thanks, Wm William Dixon Program Manager - Internet Protocol Security Windows Operating Systems Division Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: WDixon@microsoft.com (preferred), Work: 425-703-8729 Microsoft VPN Position Whitepaper: http://www.microsoft.com/windows/server/technical/networking/NWPriv.asp The Win2000 Beta3 IPSec walkthrough, under Security: http://www.microsoft.com/windows/server/Deploy/default.asp 3DES support in IPSec is obtained by installing the High Encryption Pack at: http://www.microsoft.com/windows/server/beta/downloads/128bit/default.asp Windows 2000 IPSec Interop external web site: http://w2kipsec-pub.rte.microsoft.com From owner-ipsec@lists.tislabs.com Thu Dec 9 07:16:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26881; Thu, 9 Dec 1999 07:16:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09339 Thu, 9 Dec 1999 08:43:58 -0500 (EST) To: ipsec@lists.tislabs.com Subject: RE: heartbeats (summary of responses) Date: Thu, 9 Dec 1999 09:50:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0034@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Slava Kavsan [mailto:bkavsan@ire-ma.com] > Sent: 09 December 1999 08:00 > To: Tero Kivinen > Cc: Andrew Krywaniuk; ipsec@lists.tislabs.com > Subject: Re: heartbeats (summary of responses) > > > Tero Kivinen wrote: > > > The other one will then start sending those packets using > that SA just > > negotiated. The ip address must be from the range that is covered by > > the quick mode selectors. > > Tero, > > Interesting idea. Question: how do you send ICMP heartbeats > on IPSec SAs that are restricted to TCP-only or UDP-only protocols? Or IPSEC SAs that don't include the gateway addresses? Chris From owner-ipsec@lists.tislabs.com Thu Dec 9 07:46:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27625; Thu, 9 Dec 1999 07:46:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09573 Thu, 9 Dec 1999 09:24:09 -0500 (EST) Date: Thu, 9 Dec 1999 09:27:44 -0500 Message-Id: <199912091427.JAA10994@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcr@sandelman.ottawa.on.ca Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <384EFC36.46AC3B26@ire-ma.com> <199912090055.TAA18192@istari.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael C Richardson writes: >>>>> "Bronislav" == Bronislav Kavsan writes: Bronislav> If gateway protects internal subnet Bronislav> 199.34.57.0/255.255.255.0 and has internal address Bronislav> 199.34.57 27 - how Client would know this internal gateway Bronislav> address in order to ping it? Do you Michael> My opinion is that clients don't do heartbeats, since they Michael> don't have 2000 SAs that they want to track. But there are other reasons to do heartbeats. For example, if you want to verify that the security gateway still knows about your SAs (so you can negotiate new ones if the old ones have vanished for some reason). As far as I can see, this "black hole detection" is a valuable, perhaps the most valuable, benefit of heartbeat. paul From owner-ipsec@lists.tislabs.com Thu Dec 9 07:51:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27768; Thu, 9 Dec 1999 07:51:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09636 Thu, 9 Dec 1999 09:34:09 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD68B@exchange> From: Stephane Beaulieu To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) Date: Thu, 9 Dec 1999 09:40:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But there are other reasons to do heartbeats. For example, if you > want to verify that the security gateway still knows about your SAs > (so you can negotiate new ones if the old ones have vanished for some > reason). As far as I can see, this "black hole detection" is a > valuable, perhaps the most valuable, benefit of heartbeat. Paul, Is this really necessary though? Presumably if you sent traffic on an IPsec SA with a SPI that the gateway doesn't recognize, the gw will send you an authenticated INVALID_SPI notify, which should tell the Client that the IPsec SA is gone. Of course this requires the presence of a phase 1 SA. However, this is why the INVALID_SPI notify is there isn't it? Stephane. From owner-ipsec@lists.tislabs.com Thu Dec 9 08:21:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28413; Thu, 9 Dec 1999 08:21:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09714 Thu, 9 Dec 1999 09:57:17 -0500 (EST) Date: Thu, 9 Dec 1999 10:00:50 -0500 Message-Id: <199912091500.KAA11017@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: sbeaulieu@TimeStep.com Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats (was RE: keepalives) References: <319A1C5F94C8D11192DE00805FBBADDFFFD68B@exchange> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephane" == Stephane Beaulieu writes: >> But there are other reasons to do heartbeats. For example, if you >> want to verify that the security gateway still knows about your >> SAs (so you can negotiate new ones if the old ones have vanished >> for some reason). As far as I can see, this "black hole >> detection" is a valuable, perhaps the most valuable, benefit of >> heartbeat. Stephane> Paul, Stephane> Is this really necessary though? Presumably if you sent Stephane> traffic on an IPsec SA with a SPI that the gateway doesn't Stephane> recognize, the gw will send you an authenticated Stephane> INVALID_SPI notify, which should tell the Client that the Stephane> IPsec SA is gone. Of course this requires the presence of Stephane> a phase 1 SA. However, this is why the INVALID_SPI notify Stephane> is there isn't it? I don't think that will help. First of all, the gateway may not have a phase 1 SA either. Second, I think many gateways will adamantly refuse to send invalid_spi notifies on the grounds that they aren't about to be suckered into using a lot of resources to respond to such a trivial DoS attack. paul From owner-ipsec@lists.tislabs.com Thu Dec 9 10:00:20 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29612; Thu, 9 Dec 1999 10:00:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09923 Thu, 9 Dec 1999 11:25:26 -0500 (EST) Message-Id: <384FD8D1.D462B77F@xedia.com> Date: Thu, 09 Dec 1999 11:29:05 -0500 From: Leonard Schwartz X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Tero Kivinen Cc: Slava Kavsan , Andrew Krywaniuk , ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> <384F0B1F.7F005895@ire-ma.com> <199912090537.HAA16730@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > Slava Kavsan writes: > > My vote goes to Phase1-based hearbeats using never-going-away IKE > > SAs (or skeletal ones for resource-restricted implementations - just > > enough to protect Informational messages). > > I don't think people want to implement "skeletal IKE SAs". More code, > more special cases, uncommon code path == untested code == lots of > bugs... > > BTW, I am not really happy having the IKE SA to transfer more and more > data. Currently the IKE can happily be in user mode and use software > encryption, because the amount of data to be transferred is that > small. If we start sending hearbeats inside the IKE message we also > might end up consuming our randomness quite fast. For each IKE message > we need to create random message id and a random nonce. > > > I would also like to suggest using Ack-ed NOTIFY mechanism and not > > to invent yet another scheme. Heartbeat management messages will > > also be useful. > > If we really want to have phase 1 heartbeat, I think one way notify > from both ends using negotiated interval is the right way to do. > > Anyways I think phase 2 heartbeats are the ones we want to move > forward, and preferredly we are using just normal ping packets to the > some ip-address of the other end. > Tero, consider the case when 2 gateways have many (hundreds or thousands) tunnels between them. Running phase 2 heartbeats for each IPSec SA pair between gateways will not scale. You may suggest that multiple IPSec tunnels between 2 IPSec gateways is not a terribly useful configuration but it can be done. One the other hand phase 1 heartbeats do not have the same problem. > > I.e during the Phase 2 SA negotiation, the initiator or responder will > send REQUEST_HEARTBEATS notify, which contains ip-number and interval > to use inside the notification data field (as data attribute list). > > The other one will then start sending those packets using that SA just > negotiated. The ip address must be from the range that is covered by > the quick mode selectors. > > Either end can enable it, and the other end will acknowledge the > willingness of doing it by starting to send heartbeats packets. The > requestor can see if the other end is up and running by watching for > those ping packets, and it will reply to them in normal way. If it > never sees any ping packets it must assume that the other end does not > support heartbeats, and disable the feature. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -- +--------------------------------+ | Leonard Schwartz | | Lucent Technologies | | 50 Nagog Park | | Acton, MA 01720 | | TEL (978)-263-0060 x150 | +--------------------------------+ From owner-ipsec@lists.tislabs.com Thu Dec 9 11:39:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01147; Thu, 9 Dec 1999 11:39:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10325 Thu, 9 Dec 1999 13:04:55 -0500 (EST) Message-ID: <384FF01B.FFE58262@redcreek.com> Date: Thu, 09 Dec 1999 10:08:27 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Leonard Schwartz , Tero Kivinen , Slava Kavsan , Andrew Krywaniuk Subject: Re: heartbeats (summary of responses) References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> <384F0B1F.7F005895@ire-ma.com> <199912090537.HAA16730@torni.ssh.fi> <384FD8D1.D462B77F@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Leonard Schwartz wrote: > > Tero Kivinen wrote: > > > Slava Kavsan writes: > > > My vote goes to Phase1-based hearbeats using never-going-away IKE > > > SAs (or skeletal ones for resource-restricted implementations - just > > > enough to protect Informational messages). > > > > I don't think people want to implement "skeletal IKE SAs". More code, > > more special cases, uncommon code path == untested code == lots of > > bugs... > > > > BTW, I am not really happy having the IKE SA to transfer more and more > > data. Currently the IKE can happily be in user mode and use software > > encryption, because the amount of data to be transferred is that > > small. If we start sending hearbeats inside the IKE message we also > > might end up consuming our randomness quite fast. For each IKE message > > we need to create random message id and a random nonce. > > > > > I would also like to suggest using Ack-ed NOTIFY mechanism and not > > > to invent yet another scheme. Heartbeat management messages will > > > also be useful. > > > > If we really want to have phase 1 heartbeat, I think one way notify > > from both ends using negotiated interval is the right way to do. > > > > Anyways I think phase 2 heartbeats are the ones we want to move > > forward, and preferredly we are using just normal ping packets to the > > some ip-address of the other end. > > > > Tero, consider the case when 2 gateways have many (hundreds or > thousands) tunnels between them. Running phase 2 heartbeats for each > IPSec SA pair between gateways will not scale. You may suggest that > multiple IPSec tunnels between 2 IPSec gateways is not a terribly useful > configuration but it can be done. One the other hand phase 1 heartbeats > do not have the same problem. Howdy () One extra dedicated pinging phase 2 SA pair per gateway pair scales even better in this scenario. But alas, this idea scales destrucivly when hundreds || thousands of clients want to connect to a gateway. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Thu Dec 9 11:41:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01186; Thu, 9 Dec 1999 11:41:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10392 Thu, 9 Dec 1999 13:27:30 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDFFFD840@exchange> From: Andrew Krywaniuk To: Ricky Charlet , ipsec@lists.tislabs.com Cc: Leonard Schwartz , Tero Kivinen , Slava Kavsan , Andrew Krywaniuk Subject: RE: heartbeats (summary of responses) Date: Thu, 9 Dec 1999 13:32:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Tero, consider the case when 2 gateways have many (hundreds or > > thousands) tunnels between them. Running phase 2 heartbeats for each > > IPSec SA pair between gateways will not scale. You may suggest that > > multiple IPSec tunnels between 2 IPSec gateways is not a > terribly useful > > configuration but it can be done. One the other hand phase > 1 heartbeats > > do not have the same problem. > > Howdy () > One extra dedicated pinging phase 2 SA pair per gateway > pair scales > even better in this scenario. But alas, this idea scales destrucivly > when hundreds || thousands of clients want to connect to a gateway. Hi, I don't understand this particular objection to SA-referenced heartbeats. Yes, in the scenerio where you have thousands of SAs between two gateways, it is much more efficient to have one dedicated host-referenced heartbeat link, but it's just an economy of scale. If you have thousands of SAs between two gateways then you've probably got mega-giga-googlebit traffic going on that link, so 64 bytes per SA per minute is going to get lost in the shuffle... Unless, of course, these are transient SAs, in which case you should implement inactivity timeouts. In the case of thousands of clients connecting to one gateway it's the same thing. With one SA per peer, Host-referenced and SA-referenced heartbeats give you essentially the same performance. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Dec 9 11:59:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01445; Thu, 9 Dec 1999 11:59:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10439 Thu, 9 Dec 1999 13:38:00 -0500 (EST) Date: Thu, 9 Dec 1999 10:40:51 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Valery Smyslov cc: ipsec@lists.tislabs.com, Sami Vaarala , Kanta Matsuura , Bronislav Kavsan Subject: Re: cookie verification In-Reply-To: <199912091204.PAA07910@relay1.trustworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Photuris protocol also has a concept of responder enforcing resource limit per peer, in the cookie exchange step. Although the attacker may spoof different source IP addresses, to overcome this limit, the attacker must also be able to receive the cookie responses for all the packets, which may not be so trivial, because he is spoofing the IP source address on the cookie requests. -chinna On Thu, 9 Dec 1999, Valery Smyslov wrote: > On 9 Dec 99, at 10:55, Sami Vaarala wrote: > > Sami, > > > Kanta, > > > > > Hi, > > > The use of IKE Cookie in a draft > > > http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt > > > is better in terms of statelessness. > > > > Indeed it is: the first message does not require a responder > > to store state. An approach similar to this one (with > > regards to re-sending the data in the first message later) > > could work for other IKE modes as well, without making the > > exchanges longer. I wonder if this could be done easily > > using a "standard transform" to a given stateful mode? > > I thought about this also. Resending the data in the first message > later has its disadvantages when the amount of data is big enough. > And it is the first IKE packet where this often may be true - unlike > the other IKE packets, which size is limited (unless you send a lot > of certs or VendorID payloads), the first packet may contain SA with > hundreds of proposals. Resending such amound of data only for anti- > clogging purposes seems not to be a reasonable. Perhaps adding one > more roundtrip of pure cookie exchange would be better. But, > unfortunately, in any case it requires modification of IKE. > > > As an aside, how do you prevent an attacker from doing a > > "cookie jar" attack? A malicious initiator can initiate > > new exchanges by sending the first message and receiving > > the second message of each exchange, and then calculate > > the appropriate third messages corresponding to each new > > exchange -- without sending them immediately. After > > collecting eg 1000 valid responses, he can send them all > > at once to swamp the responder. > > > > Admittedly, the attacker will have to do a roughly equal > > amount of work, but over a longer period of time (and thus > > he will not be swamped). The responder can not know how > > old each of the messages are, so he will accept them. > > (The local secret for cookie generation can, of course, > > be changed once in a while, but that interval may be > > long enough to pull the attack off?) > > I guess, in this case you need to change local secret with an > interval equal to one you agree to accept your cookie within (more > precisely, you need to change it twice more frequently and keep two > last secrets and try both). > > > If the responder cookie in the draft included time, the > > responder could roughly estimate the age of the cookie > > (and thus the exchange) upon receiving the third message, > > and refuse to participate if the cookie is older than eg > > 15 seconds. > > > > As I said earlier, our cookie generation method allows us > > to determine the age of the cookie with quite a good > > resolution. If applied to this draft, upon receiving the > > third message the responder would verify the cookie and > > determine its age (eg resolution of a second). It would > > then ignore the message if it was older than what we're > > willing to accept. > > > > If you'd be interested I could document the cookie generation > > method we're using -- perhaps this would be useful for your > > draft? > > Please, do it. I think it would be useful anyway. > > > Sami > > > > -- > > Sami Vaarala (sami.vaarala@netseal.com) > > NetSeal Technologies > > http://www.netseal.com/ > > Regards, > Valera Smyslov. > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Dec 9 15:14:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04069; Thu, 9 Dec 1999 15:14:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10963 Thu, 9 Dec 1999 16:44:02 -0500 (EST) Date: Thu, 9 Dec 1999 23:47:42 +0200 (EET) Message-Id: <199912092147.XAA24564@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) In-Reply-To: <384FF01B.FFE58262@redcreek.com> References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> <384F0B1F.7F005895@ire-ma.com> <199912090537.HAA16730@torni.ssh.fi> <384FD8D1.D462B77F@xedia.com> <384FF01B.FFE58262@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet writes: > > Tero, consider the case when 2 gateways have many (hundreds or > > thousands) tunnels between them. Running phase 2 heartbeats for each > > IPSec SA pair between gateways will not scale. You may suggest that > > multiple IPSec tunnels between 2 IPSec gateways is not a terribly useful > > configuration but it can be done. One the other hand phase 1 heartbeats > > do not have the same problem. If you have hundreds or thousands IPsec SA, and you dont want to run heartbeats on all of them, why did you requested them in the first place? There only way all of those 100-1000 SAs are sending those heartbeat packets is bacause one end requested them on that SA. In normal case gateway can just check that it already have one SA that is sending heartbeat from that other gateway, I don't need yet another one, so I don't request heartbeats now. Also if you really have 100-1000 SAs between two gateways, then you propably want to configure just one SA to send those heartbeats and that SA doesn't do anything else. > One extra dedicated pinging phase 2 SA pair per gateway pair scales > even better in this scenario. But alas, this idea scales destrucivly > when hundreds || thousands of clients want to connect to a gateway. If we can request any phase 2 SA to also carry heartbeat packets (provided it can move ICMP traffic in first place), then you can either use only one dedicated SA between gateways, or you can use normal traffic SAs between clients and gateways. This kind of protocol allows you to have both setups, and the adminstrator (or the implementator) can decide which way he wants them to be. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 9 15:14:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04081; Thu, 9 Dec 1999 15:14:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10950 Thu, 9 Dec 1999 16:38:58 -0500 (EST) Date: Thu, 9 Dec 1999 23:42:34 +0200 (EET) Message-Id: <199912092142.XAA24427@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: RE: heartbeats (summary of responses) In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B81D0034@baltimore.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D0034@baltimore.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge writes: > > > The other one will then start sending those packets using > > that SA just > > > negotiated. The ip address must be from the range that is covered by > > > the quick mode selectors. > > Interesting idea. Question: how do you send ICMP heartbeats > > on IPSec SAs that are restricted to TCP-only or UDP-only protocols? If you are doing TCP/UDP based policies, then you propably have multiple SAs between hosts anyways, so you can instead create one SA just for ICMP traffic (i.e. create one SA only for ICMP traffic, and request heartbeats only from that SA). > Or IPSEC SAs that don't include the gateway addresses? It doesn't matter, because the notify already includes the ip-address to use. There is no need to have gateways ip address anywhere. The ip-address given in the notify payload doesn't have to be one of the gateways, it can give any ip-address it wants, provided that it is covered by the quick mode selectors. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 9 16:21:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05108; Thu, 9 Dec 1999 16:21:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11224 Thu, 9 Dec 1999 18:07:47 -0500 (EST) Message-ID: <38503711.9BCC0011@redcreek.com> Date: Thu, 09 Dec 1999 15:11:13 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) References: <319A1C5F94C8D11192DE00805FBBADDFFFD5DC@exchange> <384F0B1F.7F005895@ire-ma.com> <199912090537.HAA16730@torni.ssh.fi> <384FD8D1.D462B77F@xedia.com> <384FF01B.FFE58262@redcreek.com> <199912092147.XAA24564@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > > Ricky Charlet writes: > > > Tero, consider the case when 2 gateways have many (hundreds or > > > thousands) tunnels between them. Running phase 2 heartbeats for each > > > IPSec SA pair between gateways will not scale. You may suggest that > > > multiple IPSec tunnels between 2 IPSec gateways is not a terribly useful > > > configuration but it can be done. One the other hand phase 1 heartbeats > > > do not have the same problem. > > If you have hundreds or thousands IPsec SA, and you dont want to run > heartbeats on all of them, why did you requested them in the first > place? There only way all of those 100-1000 SAs are sending those > heartbeat packets is bacause one end requested them on that SA. In > normal case gateway can just check that it already have one SA that is > sending heartbeat from that other gateway, I don't need yet another > one, so I don't request heartbeats now. Howdy () I agree with your post 100% but you misquote me. That is a quote I included from Andrew. I my reply to Andrew, I said much the same thing as you. No harm done though. :-) -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Thu Dec 9 16:25:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05165; Thu, 9 Dec 1999 16:25:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11287 Thu, 9 Dec 1999 18:26:01 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0102D242@exchange> From: Andrew Krywaniuk To: Ricky Charlet , Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: RE: heartbeats (summary of responses) Date: Thu, 9 Dec 1999 18:32:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Ricky Charlet writes: > > > > Tero, consider the case when 2 gateways have many (hundreds or ... > Howdy () > I agree with your post 100% but you misquote me. That > is a quote I > included from Andrew. I my reply to Andrew, I said much the same thing > as you. No harm done though. :-) Ironically, no. I'm afraid that it's actually a quote from Leonard. Still no harm done, though. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Thursday, December 09, 1999 6:11 PM > To: Tero Kivinen > Cc: ipsec@lists.tislabs.com > Subject: Re: heartbeats (summary of responses) > > > Tero Kivinen wrote: > > > > Ricky Charlet writes: > > > > Tero, consider the case when 2 gateways have many (hundreds or > > > > thousands) tunnels between them. Running phase 2 > heartbeats for each > > > > IPSec SA pair between gateways will not scale. You may > suggest that > > > > multiple IPSec tunnels between 2 IPSec gateways is not > a terribly useful > > > > configuration but it can be done. One the other hand > phase 1 heartbeats > > > > do not have the same problem. > > > > If you have hundreds or thousands IPsec SA, and you dont want to run > > heartbeats on all of them, why did you requested them in the first > > place? There only way all of those 100-1000 SAs are sending those > > heartbeat packets is bacause one end requested them on that SA. In > > normal case gateway can just check that it already have one > SA that is > > sending heartbeat from that other gateway, I don't need yet another > > one, so I don't request heartbeats now. > > Howdy () > I agree with your post 100% but you misquote me. That > is a quote I > included from Andrew. I my reply to Andrew, I said much the same thing > as you. No harm done though. :-) > > -- > #################################### > # Ricky Charlet > # (510) 795-6903 > # rcharlet@redcreek.com > #################################### > > end Howdy; > From owner-ipsec@lists.tislabs.com Thu Dec 9 16:27:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05196; Thu, 9 Dec 1999 16:27:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11245 Thu, 9 Dec 1999 18:20:58 -0500 (EST) Message-Id: <199912091340.IAA00374@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) In-reply-to: Your message of "Wed, 08 Dec 1999 21:37:27 EST." <384F15E2.9BC843C3@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Dec 1999 08:40:10 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> If you talking about deleting _unexpired_ IKE SAs when there is a Slava> quiet period as far as heartbeats - and then you re-negotiate it Slava> when there is a need for a heartbeat - I see at least two problems Slava> with it: 1) possibility of re-negotiating IKE SAs more frequently Slava> than their expiration time - i.e. if IKE SA set to expire in 4 Slava> hours - you may end up re-negotiating it every hour (just a If the user goes away, the odds are that they will come back with a different IP address, so you have to renegotiate anyway. The heartbeat permits one to identify unused SAs. If you want to expire them, fine. I think that I would simply unload them into some secondary storage if available if the primary got short of space. The point of heartbeats is to permit gateways to identify clients who disconnected by unplugging the modem. Now, if you keep the phase 1 SA around, you might permit a user to rekey from a different IP address, but I don't think that it would be interoperable. Slava> But if you talking about keeping IKE SA till it _expires_ and do Slava> not re-negotiate it until you need it again - I would agree with Slava> you. If you can afford to keep all SAs until they expire, then you should do so, period. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Dec 9 16:31:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05238; Thu, 9 Dec 1999 16:31:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11251 Thu, 9 Dec 1999 18:21:02 -0500 (EST) Message-Id: <199912091335.IAA00364@pzero.sandelman.ottawa.on.ca> To: IP Security List Subject: Re: Heartbeats (was RE: keepalives) In-reply-to: Your message of "Wed, 08 Dec 1999 21:46:24 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Dec 1999 08:35:05 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Henry" == Henry Spencer writes: Henry> "Michael C. Richardson" wrote: >> I don't see any complexity, since you see the heartbeat coming out >> of the descryption routines, and not even pass it to the routing engine. Henry> Unfortunately, this puts yet another special case right in the main path, Henry> the one that you want to optimize. In general, this is not a good thing. Henry> This sort of signalling really ought to use an out-of-band path. While I agree with you, that this is a critical path, I don't agree that this is a special case. It is in fact just a another exit condition on the tunnel to check. A good implementation will make use of hash tables on key fields to find appropriate exit conditions, and this can be done quite simply in this context. Some hardware implementations won't have a problem at all, since they can check tunnel exit conditions in O(1) -- independant of the number of exit conditions. And, you only need to recognize the return ping if you want to subtract it from the accounting data, otherwise, you just let it flow, and the IP stack on the inside of the gateway eats it as a ping response, as it would any other ping response. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface iQB1AwUBOE+wB45hrHmwwFrtAQGiGgL/ZocHKreJDWTXfGnbMB+LcA7liQJZJ44p iAlQ0jsLQ9NVu279C5vViaWMutHdPPT49A9ShC8SkrDL+inIld1YA/ulRrCprPOb U1oF46YGy7GuFbQKqmiBNnBsgMdO33Au =1vsT -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Dec 9 16:34:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05288; Thu, 9 Dec 1999 16:34:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11238 Thu, 9 Dec 1999 18:19:52 -0500 (EST) Message-Id: <199912091351.IAA00400@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: heartbeats (summary of responses) In-reply-to: Your message of "Thu, 09 Dec 1999 03:00:12 EST." <384F618B.238B553C@ire-ma.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Dec 1999 08:51:32 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Slava" == Slava Kavsan writes: Slava> Tero Kivinen wrote: >> The other one will then start sending those packets using that SA just >> negotiated. The ip address must be from the range that is covered by >> the quick mode selectors. Slava> Tero, Slava> Interesting idea. Question: how do you send ICMP heartbeats on Slava> IPSec SAs that are restricted to TCP-only or UDP-only protocols? a) You don't. In the case that you have such restricted SAs, you probably have a lot of them, and a heartbeat SA won't kill you. Or you do without heartbeats, and depend upon the reception of traffic from the other end (TCP will retransmit) to infer that the other end is alive. b) You have the general problem with these restricted SAs that it doesn't accomodate ICMP error messages (i.e. host unreachable) so you can't even detect if the end-host is down, and you should fail-over. I've written extensively about this, so I won't say anymore. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Dec 9 16:56:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05504; Thu, 9 Dec 1999 16:56:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11384 Thu, 9 Dec 1999 18:53:16 -0500 (EST) Message-Id: <199912092355.SAA00783@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-reply-to: Your message of "Thu, 09 Dec 1999 09:27:44 EST." <199912091427.JAA10994@tonga.xedia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Dec 1999 18:55:00 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: >>>>> "Michael" == Michael C Richardson writes: >>>>> "Bronislav" == Bronislav Kavsan writes: Bronislav> If gateway protects internal subnet Bronislav> 199.34.57.0/255.255.255.0 and has internal address Bronislav> 199.34.57 27 - how Client would know this internal gateway Bronislav> address in order to ping it? Do you Michael> My opinion is that clients don't do heartbeats, since they Michael> don't have 2000 SAs that they want to track. Paul> But there are other reasons to do heartbeats. For example, if you Paul> want to verify that the security gateway still knows about your SAs Paul> (so you can negotiate new ones if the old ones have vanished for some Paul> reason). As far as I can see, this "black hole detection" is a Paul> valuable, perhaps the most valuable, benefit of heartbeat. If there is traffic flowing, then the SA is alive. If you want to insert a ping, and need an address, and the ping will fit into the SA in the first place, then ping the remote end of an open TCP connection. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Dec 9 18:56:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16700; Thu, 9 Dec 1999 18:56:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11676 Thu, 9 Dec 1999 20:44:30 -0500 (EST) Message-Id: <9912100200.AA02802@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Fri, 10 Dec 1999 11:00:30 +0900 To: "Valery Smyslov" Cc: , "Sami Vaarala" , "Kanta Matsuura" , "Bronislav Kavsan" Subject: Re: cookie verification In-Reply-To: <199912091204.PAA07910@relay1.trustworks.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery, Despite the current implementations, I wonder if such amount of SA proposals are intrinsically necessary. "Valery Smyslov" wrote: >>On 9 Dec 99, at 10:55, Sami Vaarala wrote: >>> Indeed it is: the first message does not require a responder >>> to store state. An approach similar to this one (with >>> regards to re-sending the data in the first message later) >>> could work for other IKE modes as well, without making the >>> exchanges longer. I wonder if this could be done easily >>> using a "standard transform" to a given stateful mode? >> >>I thought about this also. Resending the data in the first message >>later has its disadvantages when the amount of data is big enough. >>And it is the first IKE packet where this often may be true - unlike >>the other IKE packets, which size is limited (unless you send a lot >>of certs or VendorID payloads), the first packet may contain SA with >>hundreds of proposals. Resending such amound of data only for anti- >>clogging purposes seems not to be a reasonable. Perhaps adding one >>more roundtrip of pure cookie exchange would be better. But, >>unfortunately, in any case it requires modification of IKE. --^^-- Kanta From owner-ipsec@lists.tislabs.com Fri Dec 10 00:11:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA09061; Fri, 10 Dec 1999 00:11:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12545 Fri, 10 Dec 1999 01:57:43 -0500 (EST) Date: Fri, 10 Dec 1999 16:00:23 +0900 (JST) From: Shoichi Sakane Message-Id: <199912100700.QAA01100@ghost.wide.ydc.co.jp> To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com Subject: Re: ID payload on phase 2. In-Reply-To: Your message of "Wed, 8 Dec 1999 07:16:31 -0800" References: X-Mailer: Cue version 0.6 (991209-2111/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The ID payload describes the selector for which IP packets will be > applied some IPSec transforms. If your selector is for all TCP packets : (snip) > gateway which protects 10.10.10/24 that gateway would initiate a phase > 2 exchange with IDs for 10.10.10/24/tcp/0 and 10.20.20.2/tcp/0. I have understood. What do you think about my second question ? > > Is the end of the IKE-SA's IP address always same to the IPsec-SA's ? > > If node has some IP address, then is there a potential that multiple SA > > based IP address is created, but same nodes are communicating ? Where do I get IP address of the end of the IPsec-SA from ? I am thinking that it's useful for a Mobile-IP and a node which has multiple IP addresses that IKE can exchange the IP address of the SA. It's just idea. Regards, /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Fri Dec 10 01:03:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12301; Fri, 10 Dec 1999 01:03:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12716 Fri, 10 Dec 1999 02:58:59 -0500 (EST) Message-Id: <199912100802.LAA17464@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Kanta Matsuura Date: Fri, 10 Dec 1999 11:01:42 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: cookie verification CC: , "Sami Vaarala" , "Bronislav Kavsan" In-reply-to: <9912100200.AA02802@Ichiko.imailab.iis.u-tokyo.ac.jp> References: <199912091204.PAA07910@relay1.trustworks.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 10 Dec 99, at 11:00, Kanta Matsuura wrote: Kanta, > Valery, > > Despite the current implementations, > I wonder if such amount of SA proposals are > intrinsically necessary. If initiator doesn't know beforehand responder's capabilities, he probably would include in proposals list all the combinations he supports and consideres adequate to protect this traffic. Even leaving non-standard Oakley groups and different lifetimes it is more than three hundred of combinations for Main Mode with current IKE definitions and this number will only grow as number of defined attributes and their values will grow in future. Regards, Valera Smyslov. > "Valery Smyslov" wrote: > >>On 9 Dec 99, at 10:55, Sami Vaarala wrote: > >>> Indeed it is: the first message does not require a responder > >>> to store state. An approach similar to this one (with > >>> regards to re-sending the data in the first message later) > >>> could work for other IKE modes as well, without making the > >>> exchanges longer. I wonder if this could be done easily > >>> using a "standard transform" to a given stateful mode? > >> > >>I thought about this also. Resending the data in the first message > >>later has its disadvantages when the amount of data is big enough. > >>And it is the first IKE packet where this often may be true - unlike > >>the other IKE packets, which size is limited (unless you send a lot > >>of certs or VendorID payloads), the first packet may contain SA with > >>hundreds of proposals. Resending such amound of data only for anti- > >>clogging purposes seems not to be a reasonable. Perhaps adding one > >>more roundtrip of pure cookie exchange would be better. But, > >>unfortunately, in any case it requires modification of IKE. > > --^^-- > Kanta > From owner-ipsec@lists.tislabs.com Fri Dec 10 07:05:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20771; Fri, 10 Dec 1999 07:05:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13310 Fri, 10 Dec 1999 08:36:16 -0500 (EST) To: Tero Kivinen , ipsec@lists.tislabs.com Subject: RE: heartbeats (summary of responses) Date: Fri, 10 Dec 1999 10:16:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Chris Trobridge Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D005E@baltimore.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: 09 December 1999 21:43 > To: ipsec@lists.tislabs.com > Subject: RE: heartbeats (summary of responses) > > > Chris Trobridge writes: > > Or IPSEC SAs that don't include the gateway addresses? > > It doesn't matter, because the notify already includes the ip-address > to use. There is no need to have gateways ip address anywhere. The > ip-address given in the notify payload doesn't have to be one of the > gateways, it can give any ip-address it wants, provided that it is > covered by the quick mode selectors. The end that receives this notify has to transmit the ping though(?), and it needs an address to ping from. This would preferably be its own address, unless your advocating the gateway spoofs a client address (I hope not!). It would also need to be covered by a common quick mode selector. One thing I've noticed is that while the 'public' IP address (the one used to set up the ISAKMP SA) is known to each peer, the private addresses aren't. This is one of the reasons why I think the heart beats should transmitted between gateway addresses directly. Even if you give a client address to ping to, you're now testing whether this address is up or not as well. The availability requirement on the host at this address means that it probably needs to be manually configured. eg You shouldn't just scan through the local hosts on your selector until you find one that responds to pings and offer that address. I think that anything that relies on traffic going beyond the gateway is only going to be useful in specific limited scenarios. Chris From owner-ipsec@lists.tislabs.com Fri Dec 10 09:44:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22996; Fri, 10 Dec 1999 09:44:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13788 Fri, 10 Dec 1999 11:14:33 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Fri, 10 Dec 1999 08:17:30 -0800 Message-Id: In-Reply-To: <199912081710.JAA08460@potassium.network-alchemy.com> Subject: Re: ID payload on phase 2. MIME-Version: 1.0 TO: dharkins@network-alchemy.com CC: francisco_corella@hp.com, ipsec@lists.tislabs.com, sakane@ydc.co.jp Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan and Sumit, Thanks for your answers. Sorry the question was silly. I'm new to ipsec. Francisco ================================================================================ Subject: Re: ID payload on phase 2. Author: Non-HP-dharkins (dharkins@network-alchemy.com) at HP-ColSprings,mimegw5 Date: 12/8/99 9:10 AM Why can't it contain 10.10/24/tcp/0? Look at the figure and accompanying text in 4.6.2 of RFC2407. What do you think the protocol and port fields are for? Dan. On Wed, 08 Dec 1999 07:16:31 PST you wrote > I'm confused. Are you saying that the ID payload contains a selector > such as 10.10.10/24/tcp/0? > > According to the DOI RFC (RFC 2407), Section 4.6.2, the ID payload may > contain verious kinds of addresses and names, but not selectors. It > could contain 10.10.10/24 but not 10.10.10/24/tcp/0. > > Francisco ================================================================================ > I'm confused. Are you saying that the ID payload > contains a selector > such as 10.10.10/24/tcp/0? > > According to the DOI RFC (RFC 2407), Section 4.6.2, the > ID payload may > contain verious kinds of addresses and names, but not > selectors. It > could contain 10.10.10/24 but not 10.10.10/24/tcp/0. Sure it can. Check out the format of the ID payload from section 4.6.2: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Type ! Protocol ID ! Port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note the protocol id and port fields. Sumit A. Vakil Caly Networks > > Francisco > From owner-ipsec@lists.tislabs.com Fri Dec 10 10:56:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23711; Fri, 10 Dec 1999 10:56:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14095 Fri, 10 Dec 1999 12:33:38 -0500 (EST) Date: Fri, 10 Dec 1999 12:37:16 -0500 Message-Id: <199912101737.MAA15802@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mcr@sandelman.ottawa.on.ca Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) References: <199912091427.JAA10994@tonga.xedia.com> <199912092355.SAA00783@pzero.sandelman.ottawa.on.ca> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: >>>>> "Paul" == Paul Koning writes: >>>>> "Michael" == Michael C Richardson writes: Michael> My opinion is that clients don't do heartbeats, since they Michael> don't have 2000 SAs that they want to track. Paul> But there are other reasons to do heartbeats. For example, if Paul> you want to verify that the security gateway still knows about Paul> your SAs (so you can negotiate new ones if the old ones have Paul> vanished for some reason). As far as I can see, this "black Paul> hole detection" is a valuable, perhaps the most valuable, Paul> benefit of heartbeat. Michael> If there is traffic flowing, then the SA is alive. If you Michael> want to insert a ping, and need an address, and the ping Michael> will fit into the SA in the first place, then ping the Michael> remote end of an open TCP connection. The interesting case of course is where you are sending secured traffic out but aren't receiving any back. So in that case you need a heartbeat to decide what the situation is. How can you ping the remote end of an open TCP connection? Routers don't know anything about open TCP connections. There may not be any open TCP connections, of course... paul From owner-ipsec@lists.tislabs.com Fri Dec 10 12:36:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25672; Fri, 10 Dec 1999 12:36:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14386 Fri, 10 Dec 1999 14:04:43 -0500 (EST) Message-Id: <199912101906.OAA09679@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-reply-to: Your message of "Fri, 10 Dec 1999 12:37:16 EST." <199912101737.MAA15802@tonga.xedia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Dec 1999 14:06:27 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Richardson writes: >>>>> "Paul" == Paul Koning writes: >>>>> "Michael" == Michael C Richardson writes: Michael> My opinion is that clients don't do heartbeats, since they Michael> don't have 2000 SAs that they want to track. Paul> But there are other reasons to do heartbeats. For example, if Paul> you want to verify that the security gateway still knows about Paul> your SAs (so you can negotiate new ones if the old ones have Paul> vanished for some reason). As far as I can see, this "black Paul> hole detection" is a valuable, perhaps the most valuable, Paul> benefit of heartbeat. Michael> If there is traffic flowing, then the SA is alive. If you Michael> want to insert a ping, and need an address, and the ping Michael> will fit into the SA in the first place, then ping the Michael> remote end of an open TCP connection. Paul> The interesting case of course is where you are sending secured Paul> traffic out but aren't receiving any back. So in that case you need a Paul> heartbeat to decide what the situation is. I agree. You aren't using TCP in that case, so you don't have a TCP-only SA. It might be UDP, but it isn't RPC. You might be sending multicast, in which case it makes no sense to have a heartbeat. Paul> How can you ping the remote end of an open TCP connection? Routers Paul> don't know anything about open TCP connections. There may not be any Paul> open TCP connections, of course... If you don't know about the TCP connections, then how did you open that TCP-only SA? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Dec 10 13:41:34 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26459; Fri, 10 Dec 1999 13:41:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14642 Fri, 10 Dec 1999 15:06:27 -0500 (EST) Message-Id: <199912102007.MAA15428@potassium.network-alchemy.com> To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: keepalives (was: Re: Heartbeats (was RE: keepalives)) In-reply-to: Your message of "Fri, 10 Dec 1999 14:06:27 EST." <199912101906.OAA09679@pzero.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15425.944856465.1@network-alchemy.com> Date: Fri, 10 Dec 1999 12:07:45 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 10 Dec 1999 14:06:27 EST you wrote > > Paul> How can you ping the remote end of an open TCP connection? Routers > Paul> don't know anything about open TCP connections. There may not be a >ny > Paul> open TCP connections, of course... > > If you don't know about the TCP connections, then how did you open that > TCP-only SA? You have an SA for transient traffic whose protocol is TCP. You don't have any of the TCP state for those connections. That resides on the hosts behind you. Dan. From owner-ipsec@lists.tislabs.com Fri Dec 10 14:05:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26743; Fri, 10 Dec 1999 14:05:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14768 Fri, 10 Dec 1999 15:52:26 -0500 (EST) Message-Id: <199912102054.PAA10483@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: keepalives (was: Re: Heartbeats (was RE: keepalives)) In-reply-to: Your message of "Fri, 10 Dec 1999 12:07:45 PST." <199912102007.MAA15428@potassium.network-alchemy.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Dec 1999 15:54:08 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> On Fri, 10 Dec 1999 14:06:27 EST you wrote >> Paul> How can you ping the remote end of an open TCP connection? Routers Paul> don't know anything about open TCP connections. There may not be a >> ny Paul> open TCP connections, of course... >> >> If you don't know about the TCP connections, then how did you open that >> TCP-only SA? Dan> You have an SA for transient traffic whose protocol is TCP. You don't Dan> have any of the TCP state for those connections. That resides on the hosts Dan> behind you. So, you are in a per-port/per-host gateway to gateway situation in this case, and you can afford the extra SA if you want a heartbeat. If you can't afford the one SA, then I guess you can't do the heartbeat. Please remember the problem you are trying to solve. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Dec 10 15:12:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27609; Fri, 10 Dec 1999 15:12:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14924 Fri, 10 Dec 1999 16:55:12 -0500 (EST) Message-ID: From: "Dorham, Elliot" To: ipsec@lists.tislabs.com Subject: IKE and tunneling Date: Fri, 10 Dec 1999 13:59:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. I am new to the list. Can anyone tell me if what the relationship is between IPSec and other tunneling protocols such as L2TP and PPTP. Also, during the initial IKE, are the UDP packets that are exchanged tunneled? If not, can they be, or would that have to be one of the parameters passed during a SA specification? Elliott Elliott T. Dorham, LT, USN Code 32, Information Systems Technology Naval Postgraduate School etdorham@nps.navy.mil From owner-ipsec@lists.tislabs.com Fri Dec 10 15:13:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27628; Fri, 10 Dec 1999 15:13:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14887 Fri, 10 Dec 1999 16:38:48 -0500 (EST) Message-Id: <199912102140.QAA10817@pzero.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats (was RE: keepalives) In-reply-to: Your message of "Fri, 10 Dec 1999 16:02:11 EST." <199912102102.QAA19067@tonga.xedia.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Dec 1999 16:40:32 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Koning writes: Paul> Well, in a high speed router you're DEFINITELY not going to observe Paul> packets to parse out TCP protocol operations. Not unless you have to Paul> (e.g., if you're required to do stateful firewall work). You definitely *WILL* observe TCP protocols because you have to select the right SA!!! Multiple vendors build hardware to do already, some in O(1) time, independant of the number of SAs. Paul> As for (b), I don't understand. Paul> The issue was, if I remember right: how can a security gateway do Paul> heartbeat by pinging? And how does pinging help? by observing that when traffic goes out the "send" SA, something comes back on the "receive" SA. You might want to actually see the ping packet itself, but that isn't strictly necessary. Nice, certainly, as it is provides protection against some pathological cases. Paul> If you mean that TCP will recover from temporary SA outages, that's Paul> true if the outage is short enough. But one-sided loss of SA may last Paul> for minutes or hours if there isn't a specific mechanism to recover. I'm curious about how one side loss of an SA works. Does one machine involved in the SA "half-crash"? Or is this due to a receiver side of an SA deciding that the hard k-byte limit was reached, and removing it, while the sender still thinks it is good? One disadvantage of pinging between the client and *gateway* is that it provides no protection against internal routing mishaps at headquarters. It might be better to fall-over to another gateway entirely in that situation, as it may have the appropriate internal connectivity. Without security gateways in the way, this would occur naturally via routing updates (assuming the ideal situation that the inside was routable from the outside). I'm not sure if having the client (road-warrior) ping the server really helps for gateway/intranet fail-over, but I know that pinging the gateway doesn't tell the client anything. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Sat Dec 11 13:20:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14335; Sat, 11 Dec 1999 13:20:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17231 Sat, 11 Dec 1999 14:43:03 -0500 (EST) Date: Sat, 11 Dec 1999 14:44:40 -0500 (EST) From: Henry Spencer To: "Dorham, Elliot" cc: ipsec@lists.tislabs.com Subject: Re: IKE and tunneling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 10 Dec 1999, Dorham, Elliot wrote: > Can anyone tell me if what the relationship is between IPSec and > other tunneling protocols such as L2TP and PPTP. There is none. They are some similarities in functions and approach, but they are different protocols. > Also, during > the initial IKE, are the UDP packets that are exchanged tunneled? No, the IKE packets (all of them, not just at the start) go direct from IKE implementation to IKE implementation, without any complications of that sort. The IKE implementations do their own encryption and authentication. IKE negotiates tunnels for more ordinary IP traffic, but the IKE traffic itself doesn't go through those tunnels. > If not, can they be... Once the tunnels are set up, conceivably you could send further IKE packets through them... but it's a bad idea, because if one end goes down and comes back up again -- losing all its tunnels -- then the two ends can't communicate, because the intact end is trying to send IKE packets through broken tunnels. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Sat Dec 11 21:49:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13395; Sat, 11 Dec 1999 21:49:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18029 Sat, 11 Dec 1999 23:36:23 -0500 (EST) From: "Elliott T. Dorham" To: "Henry Spencer" , "Dorham, Elliot" Cc: Subject: RE: IKE and tunneling Date: Sat, 11 Dec 1999 20:37:08 -0800 Message-ID: <000101bf445a$8cc920c0$3bcbfea9@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, Thank you for the rapid response! I have a second question: If an IPSec session goes down because of a connection being lost or for some other reason, once communications are re-established between the two hosts through either the same or different pathways, does a new SA have to be negotiated? Can I immediately begin speaking IPSec again, or must I speak IKE first to establish the parameters with which to build an IPSec SA again? Elliott T Dorham, LT., USN Naval Postgraduate School Information Systems Technology, Code 32 etdorham@nps.navy.mil >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Henry Spencer >Sent: 11 December, 1999 11:45 >To: Dorham, Elliot >Cc: ipsec@lists.tislabs.com >Subject: Re: IKE and tunneling > > >On Fri, 10 Dec 1999, Dorham, Elliot wrote: >> Can anyone tell me if what the relationship is between IPSec and >> other tunneling protocols such as L2TP and PPTP. > >There is none. They are some similarities in functions and approach, but >they are different protocols. > >> Also, during >> the initial IKE, are the UDP packets that are exchanged tunneled? > >No, the IKE packets (all of them, not just at the start) go direct from >IKE implementation to IKE implementation, without any complications of >that sort. The IKE implementations do their own encryption and >authentication. IKE negotiates tunnels for more ordinary IP traffic, >but the IKE traffic itself doesn't go through those tunnels. > >> If not, can they be... > >Once the tunnels are set up, conceivably you could send further IKE >packets through them... but it's a bad idea, because if one end goes down >and comes back up again -- losing all its tunnels -- then the two ends >can't communicate, because the intact end is trying to send IKE packets >through broken tunnels. > > Henry Spencer > henry@spsystems.net > >(henry@zoo.toronto.edu) > From owner-ipsec@lists.tislabs.com Sun Dec 12 09:58:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26616; Sun, 12 Dec 1999 09:58:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19138 Sun, 12 Dec 1999 11:38:48 -0500 (EST) Message-ID: <3853CFC6.4B0A4233@cisco.com> Date: Sun, 12 Dec 1999 11:39:34 -0500 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: "Dorham, Elliot" , ipsec@lists.tislabs.com Subject: Re: IKE and tunneling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > > On Fri, 10 Dec 1999, Dorham, Elliot wrote: > > Can anyone tell me if what the relationship is between IPSec and > > other tunneling protocols such as L2TP and PPTP. > > There is none. They are some similarities in functions and approach, but > they are different protocols. Different protocols, yes, however L2TP mandates the use of IPsec for security on IP networks. This Internet Draft discusses some of the issues involved. There is a new version actively in the works as well. http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-security-05.txt - Mark From owner-ipsec@lists.tislabs.com Sun Dec 12 09:58:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26615; Sun, 12 Dec 1999 09:58:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19092 Sun, 12 Dec 1999 11:33:28 -0500 (EST) Date: Sun, 12 Dec 1999 18:33:09 +0200 (IST) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: francisco_corella@hp.com cc: ipsec@lists.tislabs.com Subject: Re: A fix for main mode with preshared keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 7 Dec 1999 francisco_corella@hp.com wrote: [........] > But there is no reason why the keying material should be derived from > these two sources. In other protocols that use ephemeral > Diffie-Hellman, the keying material is derived only from the > Diffie-Hellman secret. Mixing both g^xy and the pre-shared key provides additional strength to the protocol: even if the DH group is eventually cryptanalyzed you still need to know what the pre-shared key was in order to find the keys that protect(ed) the ipsec traffic (this may seem as a surrealistic improvement for whoever believes that no DH group in use today will ever be cryptanalyzed -- but I prefer to be in the safe side when the improvement costs nothing). For the problem at hand, I prefer the solution (as described by Dan Harkins) via ID_KEY_ID. If for whatever reasons (e.g., to avoid tracing attacks via repeated ID_KEY_ID values, though Dan's solution refers to that too) one still wants a solution of the type outlined by Francisco in the next paragraph: > > So I'd like to propose that we derive the keying material exclusively > from the Diffie-Hellman secret. One way of doing this with minimal > change to the existing protocol is simply to change > > SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) > SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) > SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) > > to > > SKEYID_d = hash(g^xy | CKY-I | CKY-R | 0) > SKEYID_a = hash(SKEYID_d | g^xy | CKY-I | CKY-R | 1) > SKEYID_e = hash(SKEYID_a | g^xy | CKY-I | CKY-R | 2) > > I believe this solves the problem. > then I suggest a different change: leave the definition of SKEYID_d and SKEYID_a unchanged (why weaken unnecessarily the really important keys?), and change SKEYID_e to: SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2) this preserves the general design in IKE by which the prf "hashes" the value g^xy in order to extract the "computational entropy" from the DH key. It weakens a bit SKEYID_e but this only impacts the security of identity protection. It leaves SKEYID_d and SKEYID_a (and thus the main security of IKE) unchanged. Hugo From owner-ipsec@lists.tislabs.com Sun Dec 12 12:13:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA27645; Sun, 12 Dec 1999 12:13:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19437 Sun, 12 Dec 1999 13:59:23 -0500 (EST) Date: Sun, 12 Dec 1999 14:01:40 -0500 (EST) From: Henry Spencer To: "Elliott T. Dorham" cc: ipsec@lists.tislabs.com Subject: RE: IKE and tunneling In-Reply-To: <000101bf445a$8cc920c0$3bcbfea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 11 Dec 1999, Elliott T. Dorham wrote: > I have a second question: If an IPSec session goes down because of a > connection being lost or for some other reason, once communications are > re-established between the two hosts through either the same or different > pathways, does a new SA have to be negotiated? It depends on exactly what happened. Simply losing connectivity between the two hosts, temporarily, won't break the IPSEC connection, provided neither end gets impatient and unilaterally declares the connection dead. Since SAs are usually rekeyed (i.e., replaced by new ones) regularly, that will happen *eventually*, but not right away. The precise path by which packets are flowing is irrelevant; the IPSEC implementations neither know nor care about that. The main reason why an IPSEC connection would be lost and have to be rebuilt is if one side crashes and reboots... and even that is not absolutely guaranteed. It's technically possible to preserve enough information across a crash to restore network connections, although few systems actually do that. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Sun Dec 12 17:26:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00994; Sun, 12 Dec 1999 17:26:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19994 Sun, 12 Dec 1999 19:13:21 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Sun, 12 Dec 1999 16:17:01 -0800 Message-Id: In-Reply-To: Subject: Re: A fix for main mode with preshared keys MIME-Version: 1.0 TO: hugo@ee.technion.ac.il CC: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, I like very much your solution based on redifining SKEYID_e. Concerning the ID_KEY_ID solution, if I understand it correctly, it works when the key is shared between two parties only. It does not work in the case where it is shared by multiple parties (e.g. all machines in a given domain). And in the case of two parties, it has the synchronization problems that were pointed out by Andrew Krywaniuk. So I think the SKEYD_e solution is much better. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A fix for main mode with preshared keys Author: Non-HP-hugo (hugo@ee.technion.ac.il) at HP-ColSprings,mimegw5 Date: 12/12/99 8:33 AM On Tue, 7 Dec 1999 francisco_corella@hp.com wrote: [........] > But there is no reason why the keying material should be derived from > these two sources. In other protocols that use ephemeral > Diffie-Hellman, the keying material is derived only from the > Diffie-Hellman secret. Mixing both g^xy and the pre-shared key provides additional strength to the protocol: even if the DH group is eventually cryptanalyzed you still need to know what the pre-shared key was in order to find the keys that protect(ed) the ipsec traffic (this may seem as a surrealistic improvement for whoever believes that no DH group in use today will ever be cryptanalyzed -- but I prefer to be in the safe side when the improvement costs nothing). For the problem at hand, I prefer the solution (as described by Dan Harkins) via ID_KEY_ID. If for whatever reasons (e.g., to avoid tracing attacks via repeated ID_KEY_ID values, though Dan's solution refers to that too) one still wants a solution of the type outlined by Francisco in the next paragraph: > > So I'd like to propose that we derive the keying material exclusively > from the Diffie-Hellman secret. One way of doing this with minimal > change to the existing protocol is simply to change > > SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) > SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) > SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) > > to > > SKEYID_d = hash(g^xy | CKY-I | CKY-R | 0) > SKEYID_a = hash(SKEYID_d | g^xy | CKY-I | CKY-R | 1) > SKEYID_e = hash(SKEYID_a | g^xy | CKY-I | CKY-R | 2) > > I believe this solves the problem. > then I suggest a different change: leave the definition of SKEYID_d and SKEYID_a unchanged (why weaken unnecessarily the really important keys?), and change SKEYID_e to: SKEYID_e = prf(hash(Ni_b | Nr_b), g^xy | CKY-I | CKY-R | 2) this preserves the general design in IKE by which the prf "hashes" the value g^xy in order to extract the "computational entropy" from the DH key. It weakens a bit SKEYID_e but this only impacts the security of identity protection. It leaves SKEYID_d and SKEYID_a (and thus the main security of IKE) unchanged. Hugo From owner-ipsec@lists.tislabs.com Sun Dec 12 18:10:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04701; Sun, 12 Dec 1999 18:10:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20144 Sun, 12 Dec 1999 20:05:06 -0500 (EST) Message-Id: <199912130106.RAA24338@potassium.network-alchemy.com> To: francisco_corella@hp.com cc: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: A fix for main mode with preshared keys In-reply-to: Your message of "Sun, 12 Dec 1999 16:17:01 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24335.945047174.1@network-alchemy.com> Date: Sun, 12 Dec 1999 17:06:14 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ID_KEY_ID is just another way of identifying a pre-shared key. If you choose to not authenticate the peer and want to have a group pre-shared key there is nothing inheirent in ID_KEY_ID that would prevent you from doing this. There are no syncronization problems with using ID_KEY_ID anymore than there are with plain identified-by-ip-address pre-shared keys. The problem came when I described a technique to prevent traffic analysis (although I think that's not really an issue but it has been raised in the past as one so I felt I should address it) by hashing the key _after_ authentication. Now the problem Andrew described was something along the lines of "what happens if my hard drive crashes and I want to restore my drive without re-syncronizing". But a security protocol is not the place to address these problems (after all what if you had a disk crash and a fire in the closet where your tapes were stored! This line of reasoning could go on forever and after all, backup tapes that contain authentication information should probably be stored in the central office so resyncronization with the database is not an issue). On the other hand, if it's such a worry then don't rehash the ID_KEY_ID; it's not necessary. But if you can live with the scaling difficulties in pre-shared keys then you can live with the scaling difficulties of uncertified public keys and use RSA encryption mode (or El-Gamal encryption mode). You get ID protection and all the rich negotiation of Main Mode. Dan. On Sun, 12 Dec 1999 16:17:01 PST you wrote > > Hugo, > > I like very much your solution based on redifining SKEYID_e. > > Concerning the ID_KEY_ID solution, if I understand it correctly, it works whe >n > the key is shared between two parties only. It does not work in the case whe >re > it is shared by multiple parties (e.g. all machines in a given domain). And >in > the case of two parties, it has the synchronization problems that were pointe >d > out by Andrew Krywaniuk. So I think the SKEYD_e solution is much better. > > Francisco From owner-ipsec@lists.tislabs.com Sun Dec 12 19:49:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA19435; Sun, 12 Dec 1999 19:49:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20363 Sun, 12 Dec 1999 21:39:38 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Sun, 12 Dec 1999 18:43:16 -0800 Message-Id: Subject: A problem with public key encrption in IKE MIME-Version: 1.0 To: ipsec@lists.tislabs.com Content-Type: text/plain; charset=US-ASCII; name="cc:Mail" Content-Disposition: inline; filename="cc:Mail" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The public key encryption methods for phase 1 authentication require the initiator to know the public key of the responder, as explained in section 6.1, 4th paragraph of the 5/99 draft. The responder does not have the option to send its certificate as part of the change. This is unfortunate, since there are cases where the initiator may have no other way of obtaining the certificate, e.g. because a certificate repository is behind a firewall. A more serious problem, however, is that the initiator may not even know the identity of the responder. This may seem odd, but it can easily happen in cases where the initiator is a gateway acting as a proxy for a client. Suppose the IP address of the responder as been assigned dynamically. The client may have learned this address in a previous exchange through the same gateway or through a different gateway. The client may then send an IP packet to this IP address, and this may cause the gateway to initiate an IKE exchange with that IP address. In this situation, the gateway, which is the initiator of the IKE exchange, knows the dynamically assigned IP address but may not know the "real" identity of the responder, the identity that determines the public key. It should be possible to fix these two problems, probably at the expense of additional messages, by first establishing the DH secret, then exchanging identities and optional certificates encrypted under a symmetric key derived from the DH secret, then exchanging the nonces encrypted under the public keys of the parties. Francisco (francisco_corella@hp.com) From owner-ipsec@lists.tislabs.com Sun Dec 12 22:28:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA25615; Sun, 12 Dec 1999 22:28:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20625 Mon, 13 Dec 1999 00:26:49 -0500 (EST) Message-Id: <199912130528.VAA24805@potassium.network-alchemy.com> To: francisco_corella@hp.com cc: ipsec@lists.tislabs.com Subject: Re: A problem with public key encrption in IKE In-reply-to: Your message of "Sun, 12 Dec 1999 18:43:16 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24802.945062922.1@network-alchemy.com> Date: Sun, 12 Dec 1999 21:28:42 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 12 Dec 1999 18:43:16 PST you wrote > The public key encryption methods for phase 1 authentication require the > initiator to know the public key of the responder, as explained in section > 6.1, 4th paragraph of the 5/99 draft. The responder does not have the > option to send its certificate as part of the change. This is unfortunate, > since there are cases where the initiator may have no other way of > obtaining the certificate, e.g. because a certificate repository is behind > a firewall. What problem are you trying to solve? This thread started because you wanted to use pre-shared keys in Main Mode and not have to bind that key to an IP address. But in that case the initiator has to know the identity of the responder anyway so I'm not sure what's the hold-up here. (Note: cert- ificates are not required, these can be uncertified public keys which are distributed in the same fashion as your pre-shared keys). > A more serious problem, however, is that the initiator may not even know > the identity of the responder. This may seem odd, but it can easily happen > in cases where the initiator is a gateway acting as a proxy for a client. > Suppose the IP address of the responder as been assigned dynamically. The n> client may have learned this address in a previous exchange through the > same gateway or through a different gateway. The client may then send an IP > packet to this IP address, and this may cause the gateway to initiate an > IKE exchange with that IP address. In this situation, the gateway, which > is the initiator of the IKE exchange, knows the dynamically assigned IP > address but may not know the "real" identity of the responder, the identity > that determines the public key. Hmmm. A gateway which has policy to an identity which it does no know. That sounds like a bogus policy right there. Forget IKE. How would you express "I want to protect packets from 'host X' to 'somewhere interesting'" if you can't know the identity of "somewhere interesting" a priori!? How would you know what to protect in that case? It doesn't seem you would. So an invalid policy which cannot be expressed in IKE doesn't seem like a problem. > It should be possible to fix these two problems, probably at the expense of > additional messages, by first establishing the DH secret, then exchanging > identities and optional certificates encrypted under a symmetric key > derived from the DH secret, then exchanging the nonces encrypted under the > public keys of the parties. What problems? You want to have a way to not bind a key to an IP address. Fine, use uncertified public keys. Then you want to have policy to a wildcard. Sorry, but things just don't work that way, and that has nothing to do with IKE. Dan. From owner-ipsec@lists.tislabs.com Sun Dec 12 22:28:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA25628; Sun, 12 Dec 1999 22:28:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20610 Mon, 13 Dec 1999 00:18:55 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Sun, 12 Dec 1999 21:22:27 -0800 Message-Id: In-Reply-To: <199912130106.RAA24338@potassium.network-alchemy.com> Subject: Re: A fix for main mode with preshared keys MIME-Version: 1.0 To: dharkins@network-alchemy.com Cc: francisco_corella@hp.com, hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, When I said that the ID_KEY_ID solution only seems to work for keys shared between two parties, I was referring to ID_KEY_ID with your method for preventing traffic analysis. Without it, ID_KEY_ID seems like a weak mechanism for identity protection, especially given that the protocol includes a DH exchange that allows you to provide proper encryption for the identities. The synchonization problem between two parties, when using the method for preventing traffic analysis, does not require a disk crash. It can also happen if there is a reboot due to a software error or power failure or anything else before the latest value of the key has been written out to secondary storage. This means that whenever there is an uncontrolled reboot, an operator will have to manually resynchronize *all* the preshared keys in case one of them has become out of sync. The redefinition of SKEYID_e described by Hugo solves the problem elegantly. If adopted, it would also clarify the IKE protocol by removing any need to rely on source IP addresses in IP packets for identification instead of relying on the ID payload. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A fix for main mode with preshared keys Author: Non-HP-dharkins (dharkins@network-alchemy.com) at HP-ColSprings,mimegw5 Date: 12/12/99 5:06 PM ID_KEY_ID is just another way of identifying a pre-shared key. If you choose to not authenticate the peer and want to have a group pre-shared key there is nothing inheirent in ID_KEY_ID that would prevent you from doing this. There are no syncronization problems with using ID_KEY_ID anymore than there are with plain identified-by-ip-address pre-shared keys. The problem came when I described a technique to prevent traffic analysis (although I think that's not really an issue but it has been raised in the past as one so I felt I should address it) by hashing the key _after_ authentication. Now the problem Andrew described was something along the lines of "what happens if my hard drive crashes and I want to restore my drive without re-syncronizing". But a security protocol is not the place to address these problems (after all what if you had a disk crash and a fire in the closet where your tapes were stored! This line of reasoning could go on forever and after all, backup tapes that contain authentication information should probably be stored in the central office so resyncronization with the database is not an issue). On the other hand, if it's such a worry then don't rehash the ID_KEY_ID; it's not necessary. But if you can live with the scaling difficulties in pre-shared keys then you can live with the scaling difficulties of uncertified public keys and use RSA encryption mode (or El-Gamal encryption mode). You get ID protection and all the rich negotiation of Main Mode. Dan. On Sun, 12 Dec 1999 16:17:01 PST you wrote > > Hugo, > > I like very much your solution based on redifining SKEYID_e. > > Concerning the ID_KEY_ID solution, if I understand it correctly, it works whe >n > the key is shared between two parties only. It does not work in the case whe >re > it is shared by multiple parties (e.g. all machines in a given domain). And >in > the case of two parties, it has the synchronization problems that were pointe >d > out by Andrew Krywaniuk. So I think the SKEYD_e solution is much better. > > Francisco From owner-ipsec@lists.tislabs.com Sun Dec 12 22:57:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA25944; Sun, 12 Dec 1999 22:57:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20663 Mon, 13 Dec 1999 00:52:34 -0500 (EST) Message-Id: <199912130554.VAA24880@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: Re: A fix for main mode with preshared keys In-reply-to: Your message of "Sun, 12 Dec 1999 21:22:27 PST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24877.945064470.1@network-alchemy.com> Date: Sun, 12 Dec 1999 21:54:30 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 12 Dec 1999 21:22:27 PST francisco_corella@hp.com wrote > > When I said that the ID_KEY_ID solution only seems to work for keys shared > between two parties, I was referring to ID_KEY_ID with your method for > preventing traffic analysis. Without it, ID_KEY_ID seems like a weak > mechanism for identity protection, especially given that the protocol > includes a DH exchange that allows you to provide proper encryption for the > identities. Why is it weak? How can you invert a blob of bits into an identity? Which frequent poster to the IPSec list does this blob of bits correspond to: 85e0a2896935d536891956d853b1243a371490f1 > The synchonization problem between two parties, when using the method for > preventing traffic analysis, does not require a disk crash. It can also > happen if there is a reboot due to a software error or power failure or > anything else before the latest value of the key has been written out to > secondary storage. This means that whenever there is an uncontrolled > reboot, an operator will have to manually resynchronize *all* the preshared > keys in case one of them has become out of sync. Then don't rehash ID_KEY_ID and tell me who that blob of bits is. But, again, this is not the type of problem that can be solved by a session establishment and key exchange protocol, the "what if" game is endless. > The redefinition of SKEYID_e described by Hugo solves the problem elegantly. > If > adopted, it would also clarify the IKE protocol by removing any need to rely >on > source IP addresses in IP packets for identification instead of relying on th >e > ID payload. What problem? It would help if you could say exactly what you're trying to solve. It started out as a way to not require keys to be bound to an IP address. But that problem is solved. So what is it that you're trying to solve now? Dan. From owner-ipsec@lists.tislabs.com Mon Dec 13 02:16:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29354; Mon, 13 Dec 1999 02:16:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21209 Mon, 13 Dec 1999 03:53:39 -0500 (EST) Message-ID: <003901bf4548$5cd22120$78253ac3@elvis.ru> From: "Valery Smyslov" To: , "Dan Harkins" References: <199912130554.VAA24880@potassium.network-alchemy.com> Subject: Re: A fix for main mode with preshared keys Date: Mon, 13 Dec 1999 11:59:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, ----- Original Message ----- From: Dan Harkins To: Sent: Monday, December 13, 1999 8:54 AM Subject: Re: A fix for main mode with preshared keys > On Sun, 12 Dec 1999 21:22:27 PST francisco_corella@hp.com wrote > > > > When I said that the ID_KEY_ID solution only seems to work for keys shared > > between two parties, I was referring to ID_KEY_ID with your method for > > preventing traffic analysis. Without it, ID_KEY_ID seems like a weak > > mechanism for identity protection, especially given that the protocol > > includes a DH exchange that allows you to provide proper encryption for the > > identities. > > Why is it weak? How can you invert a blob of bits into an identity? Which > frequent poster to the IPSec list does this blob of bits correspond to: > > 85e0a2896935d536891956d853b1243a371490f1 > > > The synchonization problem between two parties, when using the method for > > preventing traffic analysis, does not require a disk crash. It can also > > happen if there is a reboot due to a software error or power failure or > > anything else before the latest value of the key has been written out to > > secondary storage. This means that whenever there is an uncontrolled > > reboot, an operator will have to manually resynchronize *all* the preshared > > keys in case one of them has become out of sync. > > Then don't rehash ID_KEY_ID and tell me who that blob of bits is. But, again, > this is not the type of problem that can be solved by a session establishment > and key exchange protocol, the "what if" game is endless. > > > The redefinition of SKEYID_e described by Hugo solves the problem elegantly. > > If > > adopted, it would also clarify the IKE protocol by removing any need to rely > >on > > source IP addresses in IP packets for identification instead of relying on th > >e > > ID payload. > > What problem? It would help if you could say exactly what you're trying to > solve. It started out as a way to not require keys to be bound to an IP > address. But that problem is solved. So what is it that you're trying to > solve now? I think the problem is to not require keys to be bound to an IP address while using Main Mode. You solution doesn't solve this problem, while, Hugo's does. And besides, Hugo's solution makes policy lookup in IKE more uniform - you always rely only on ID payload content regardless of IKE's mode of operation. > Dan. Regards, Valera. From owner-ipsec@lists.tislabs.com Mon Dec 13 07:25:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06208; Mon, 13 Dec 1999 07:25:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21817 Mon, 13 Dec 1999 08:54:01 -0500 (EST) Message-Id: <199912131131.JAA00785@vishnu.cpd.ufjf.br> From: "Cristianne Regina Nocelli" To: ipsec@lists.tislabs.com Date: Mon, 13 Dec 1999 10:35:58 -0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Security In-reply-to: <383985D3.FFDE9765@DataFellows.com> X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Where can I find information about "conectionless integrity", "data origin authentication", "anti-replay service"? Thanks, Cristianne -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Cristianne Regina Nocelli Universidade Federal de Juiz de Fora - UFJF nocelli@csti.ufjf.br -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-ipsec@lists.tislabs.com Mon Dec 13 07:30:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06520; Mon, 13 Dec 1999 07:30:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21846 Mon, 13 Dec 1999 09:08:29 -0500 (EST) Message-ID: <19991211000856.11936.qmail@web2006.mail.yahoo.com> Date: Fri, 10 Dec 1999 16:08:56 -0800 (PST) From: sankar ramamoorthi Subject: Re: IPSec SA DELETE in "dangling" implementation To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Made a mistake while copying the message to the ipsec list. sending it again. --- Dan Harkins wrote: > You should check the archives of this list for a > good description > of the inline ISAKMP work. Basically it allowed for > the SA negotiation > to piggyback along with data to protect ala the SKIP > protocol. > > I was imagining using one of the reserved SPI > values (1 is for SKIP > and 2-255 are reserved) for a local keepalive > function. It's not thought > out very well at all and was just food for thought. > > Dan. > > On Sun, 05 Dec 1999 01:12:28 PST you wrote > > > > Can u expand on what you mean by inline ISAKMP? > > Do you mean ike control messages flowing as part > of > > ipsec data? This implies to process the control > > message > > the ipsec SA has to be alive, which seem to defeat > the > > purpose of the notification messages. > > > > I was thinking along these lines.. > > > > A crude description follows. > > > > The oneway authenticated message I described are > not > > dependent on any ipsec/ike SA. They are > independently > > authenticated messages. > > The notification message can be of the form > > header > > notification payload > > id payload > > event specific information > > authentication information > > > > The authentication information can be hash or a > > signature computed over the header, notification, > id > > payload and > > the event causing the notification (a message from > the > > peer might have caused the notification. In this > case > > the hash for the authentication information will > > include the ip packet which caused the > notification). > > In case the notification message is generated and > is > > not a response > > to a message from peer (as in the case of 'delete' > > notification), > > the hash can include spi, ipsec keys and other > > information that > > describe the event. > > > > The id payload can be used by the peer to identify > the > > corresponding policy and authenticate the > notification > > payload. An > > event specific information is also included. If > the > > notification message is generated as response to a > > message from the peer the event specific > information > > can be the ip packet from the peer. If the > > notification is generated spontaneously, the event > > specific information can contain the spi, ipsec > keys > > or other information that describe the event. The > > event specific information can be used by the > > peer to verify that the notification message is > not a > > replay attack. > > > payload > > being > > sent in the clear can be somewhat mitigated by > > The notification message is sent in the clear. Are > > there any drawbacks to this? concerns about ID > doing a > > one-way > > map of regular ID to identifier of type ID_KEY_ID > and > > sending > > the mapped identifier in the notification > messages. > > > > The advantage of oneway authenticated notification > > message that is independent of IKE/IPSec SA is > that > > they can be sent any time without the need for an > IKE > > or IPSec SA. They could carry information about > any > > IPSec or IKE SA. > > > > This way if a peer gets out of sync because the > > corresponding > > IKE or IPSec SA is absent, a notification can be > sent > > immediately > > and the peer can take corrective action > immediately. > > > > Welcome your comments on this. > > > > Thanks, > > -- sankar -- > > > > > > > > > > > > > > > On Fri, 03 Dec 1999 17:55:31 +0530 you wrote > > >> Slava Kavsan wrote: > > >> > > >> > Here is the dilemma: if "dangling" > implementation > > wants to send IPSec > > >> SA > > > > DELETE message, while the "parent" IKE SA is > no > > longer there (expired > > > or > > > > deleted), the alternatives are (and I do not > like > > either of them): > > > > > > > a) do not send DELETE > > > > b) re-negotiate IKE SA before sending DELETE > > > > > > > Any suggestions? > > > A third option is to design a oneway > authenticated > > message > > > (proofed against replay attacks). Such oneway > > authenticated message > > > can be used for 'delete', 'invalid spi' and > other > > notifications. > > > If such a design is possible then it is not > > necessary to establish > > > IKE SA to send a 'delete' notification. > > > > > > The oneway message could be authenticated using > a > > signatures > > > or hash generated using preshared secret, could > > include the > > > id payload to allow the peer to identify the > > matching shared > > > secret in the case of the pre-shared secret. The > > oneway message > > > could also use as part of the hash information > from > > the event > > > causing the notification to be generated. This > could > > prevent > > > replay attacks. > > > > > > Any thoughts on this? > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Thousands of Stores. Millions of Products. All > in one place. > > Yahoo! Shopping: http://shopping.yahoo.com > __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com From owner-ipsec@lists.tislabs.com Mon Dec 13 07:52:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07223; Mon, 13 Dec 1999 07:52:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21921 Mon, 13 Dec 1999 09:18:21 -0500 (EST) Message-ID: <009801bf4574$a9b4bb20$3e4fa8c0@iaf.fi> From: "Sami Vaarala" To: "Valery Smyslov" , "Kanta Matsuura" , "Bronislav Kavsan" Cc: References: <199912091204.PAA07910@relay1.trustworks.com> <199912100802.LAA17464@relay1.trustworks.com> Subject: Re: cookie verification Date: Mon, 13 Dec 1999 16:16:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello (and sorry for the long post), As promised, here is the cookie mechanism: H = hash(PRIV || src IP || src port || dst IP || dst port || I-COOKIE || PRIV) D = des(DKEY, AGE || AGE || AGE || COUNTER) R-COOKIE = H XOR D H is, for instance, an MD5 hash of the data shown above, where PRIV is a private octet string. (I-COOKIE is omitted when creating an initiator cookie). D is an encrypted DES block consisting of three identical 16-bit AGE fields and a COUNTER field. AGE is a 16-bit value that depends on the cookie creation time (e.g. seconds_since_boot MOD 2^16), while COUNTER is a value that increases for each cookie generation (and wraps). A cookie can be verified by calculating H (which requires only public data and no storage for the verifier) and XORing with the cookie to reveal D. D is decrypted using DKEY to obtain an 8-byte block. This is the main part: the DES block structure is verified to have the proper structure, i.e. it must consist of three identical 16-bit values followed by some 16-bit value. If not, this definitely is not a cookie we created (using DKEY and PRIV as the private secret). Probability of interpreting a random cookie as a valid one is 2^32, which can be made lower by doing better checking of the claimed AGE and COUNTER values. The cookies generated in this way have the following properties: 1. They depend on the parties in question (definition of H), and date and time (AGE, COUNTER). 2. Each generated cookie is unique, save for bad luck. Since COUNTER increases each time, a generated cookie is different even if the parties are the same (=> H is the same) and AGE is the same. [zero cookie checks have to be made; increase counter and regenerate if zero cookie was accidentally generated.] 3. Given a cookie, we can determine: (a) whether it was created by us (using the current PRIV and DKEY as private values). (b) the approximate age of the cookie, using the AGE field. 4. The cookies are unpredictable to an outsider (DKEY, PRIV). 5. Cookie generation and verification are reasonably fast (one hash calculation, one MD5 calculation). [actually twice the work for verification, because DKEY, PRIV must be changed periodically.] A simpler approach to cookie generation uses a hash which includes a private secret (plus public data) and changes the secret once in a while to protect against attacks such as "cookie jar". This is problematic for two reasons: 1. Cookie age estimations will be rough, since we can only know whether the cookie was created using the current secret or not (or with the previous one, if we try that also). 2. Each change of secret consumes entropy, since the secret must be unpredictable. Secret bytes are expensive without hardware assistance. The scheme I described is better because we can estimate cookie age more accurately, and can choose the private secret refresh frequency independently (PRIV, DKEY) of the age resolution we desire. (To conserve entropy, we could also set PRIV=DKEY.) Cookies are not a strong security feature: the worst case scenario is that the attacker will obtain DKEY and PRIV, and will be able to create cookies that we will happily accept. This will allow denial-of-service attacks until the values are changed. Of course, DKEY and PRIV MUST NOT be used for anything else in the protocol! But considering the effort of the attacker: he must cryptanalyze cookies we create to obtain DKEY and PRIV. I'm no cryptanalyst, but it seems that the effort spent in doing that costs much more than the gain of being able to do denial-of-service attacks on the server host for a limited period of time (even if update frequency is something like 15 minutes). (The cookie generation would probably be more secure if we used HMAC-MD5 (with PRIV as the key) instead of just an MD5-hash. But that needs more computation for little gain, assuming that the current scheme is hard enough to make cracking not worthwhile.) Using this cookie scheme, Matsuura's mode could avoid cookie the kind of "cookie jar" attack without storing extra state. We would simply calculate "AGE" of responder cookie in the third message of the exchange, and ensure it is fresh enough (configurable limit). If not, discard the message. Was that complicated enough? ;-) Sami -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Mon Dec 13 08:16:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07818; Mon, 13 Dec 1999 08:16:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22078 Mon, 13 Dec 1999 09:55:48 -0500 (EST) Date: Mon, 13 Dec 1999 16:59:26 +0200 (EET) Message-Id: <199912131459.QAA27116@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: francisco_corella@hp.com Cc: ipsec@lists.tislabs.com Subject: A problem with public key encrption in IKE In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk francisco_corella@hp.com writes: > It should be possible to fix these two problems, probably at the expense of > additional messages, by first establishing the DH secret, then exchanging Use signatures based authentication method, instead of rsa encryption. There IS a reason why we have different types of authentications in the IKE. They offer little bit different things... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 13 10:37:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10248; Mon, 13 Dec 1999 10:37:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22378 Mon, 13 Dec 1999 11:50:07 -0500 (EST) From: pau@watson.ibm.com Date: Mon, 13 Dec 1999 11:53:31 -0500 Message-Id: <9912131653.AA24058@secpwr.watson.ibm.com> To: francisco_corella@hp.com Subject: Re: A problem with public key encrption in IKE Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: o61FG/r8V6ZkRqxZWP4F7g== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 12 Dec 1999 18:43:16 -0800, francisco_corella@hp.com wrote : > The public key encryption methods for phase 1 authentication require the > initiator to know the public key of the responder, as explained in section > 6.1, 4th paragraph of the 5/99 draft. The responder does not have the > option to send its certificate as part of the change. This is unfortunate, > since there are cases where the initiator may have no other way of > obtaining the certificate, e.g. because a certificate repository is behind > a firewall. Francisco : I am one of the co-authors of the original pk-encryption mode draft; and indeed it was assumed that initiator knows the responder's public key when it starts the IKE negotiation. But this is really not a bug of IKE or pk-encryption mode. IMHO, the problem we have today is that there is a big gap between the internet names (IP addresses, DNS names, ...) used in IKE and the (would-be) directory structure (X500) used to search the certificates. In general, one cannot search a X509 certificate by a DNS name or an IP address. Using DNSSEC and Dynamic DNS would solve the problem, sadly the deployment is not there yet. > > A more serious problem, however, is that the initiator may not even know > the identity of the responder. This may seem odd, but it can easily happen > in cases where the initiator is a gateway acting as a proxy for a client. > Suppose the IP address of the responder as been assigned dynamically. The > client may have learned this address in a previous exchange through the > same gateway or through a different gateway. The client may then send an IP > packet to this IP address, and this may cause the gateway to initiate an > IKE exchange with that IP address. In this situation, the gateway, which > is the initiator of the IKE exchange, knows the dynamically assigned IP > address but may not know the "real" identity of the responder, the identity > that determines the public key. You can use signature mode with in-line certificates in this case. If the remote host cannot produce its certificate and signature, then most likely pk-encryption mode cannot be used neither. I must agree with Dan that the gateway will still have a hard time in determining what to do with a remote host of which the gateway knows nothing. > > It should be possible to fix these two problems, probably at the expense of > additional messages, by first establishing the DH secret, then exchanging > identities and optional certificates encrypted under a symmetric key > derived from the DH secret, then exchanging the nonces encrypted under the > public keys of the parties. IMHO, IKE should really not be twisted for every conceivable authentication/application scenarios. Then it would go down the tube as many OSI protocols, they have a little something for everyone but becomes too heavy for anyone. I personally think IKE and IPSEC are meant to provide the basic communication security, any finer-grain or more sophisticated authentication can be built on top with added ease and security assurance; but we don't have to change IKE to get all those. Pau-Chen > > Francisco > > (francisco_corella@hp.com) > From owner-ipsec@lists.tislabs.com Mon Dec 13 10:54:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10500; Mon, 13 Dec 1999 10:54:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22516 Mon, 13 Dec 1999 12:32:14 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0102D6ED@exchange> From: Andrew Krywaniuk To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: RE: heartbeats (summary of responses) Date: Mon, 13 Dec 1999 12:37:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > BTW, I am not really happy having the IKE SA to transfer more and more > data. Currently the IKE can happily be in user mode and use software > encryption, because the amount of data to be transferred is that > small. If we start sending hearbeats inside the IKE message we also > might end up consuming our randomness quite fast. For each IKE message > we need to create random message id and a random nonce. Hi Tero, I forgot to mention this before. I don't think randomness is really an issue here. It is perfectly valid to use a seeded pseudorandom number generator without consuming any additional randomness for each heartbeat. As far as I can tell, there is no security implication to using a pseudorandom message id. I suspect that the reason why we don't simply use 1,2,3... is actually to avoid collisions and not to generate entropy. I don't think this should be considered as an important argument against phase 1 heartbeats. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Thursday, December 09, 1999 12:37 AM > To: Slava Kavsan > Cc: Andrew Krywaniuk; ipsec@lists.tislabs.com > Subject: Re: heartbeats (summary of responses) > > > Slava Kavsan writes: > > My vote goes to Phase1-based hearbeats using never-going-away IKE > > SAs (or skeletal ones for resource-restricted implementations - just > > enough to protect Informational messages). > > I don't think people want to implement "skeletal IKE SAs". More code, > more special cases, uncommon code path == untested code == lots of > bugs... > > BTW, I am not really happy having the IKE SA to transfer more and more > data. Currently the IKE can happily be in user mode and use software > encryption, because the amount of data to be transferred is that > small. If we start sending hearbeats inside the IKE message we also > might end up consuming our randomness quite fast. For each IKE message > we need to create random message id and a random nonce. > > > I would also like to suggest using Ack-ed NOTIFY mechanism and not > > to invent yet another scheme. Heartbeat management messages will > > also be useful. > > If we really want to have phase 1 heartbeat, I think one way notify > from both ends using negotiated interval is the right way to do. > > Anyways I think phase 2 heartbeats are the ones we want to move > forward, and preferredly we are using just normal ping packets to the > some ip-address of the other end. > > I.e during the Phase 2 SA negotiation, the initiator or responder will > send REQUEST_HEARTBEATS notify, which contains ip-number and interval > to use inside the notification data field (as data attribute list). > > The other one will then start sending those packets using that SA just > negotiated. The ip address must be from the range that is covered by > the quick mode selectors. > > Either end can enable it, and the other end will acknowledge the > willingness of doing it by starting to send heartbeats packets. The > requestor can see if the other end is up and running by watching for > those ping packets, and it will reply to them in normal way. If it > never sees any ping packets it must assume that the other end does not > support heartbeats, and disable the feature. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Mon Dec 13 12:42:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12533; Mon, 13 Dec 1999 12:42:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22883 Mon, 13 Dec 1999 13:58:12 -0500 (EST) Message-Id: <199912131900.LAA26290@potassium.network-alchemy.com> To: "Valery Smyslov" cc: ipsec@lists.tislabs.com Subject: Re: A fix for main mode with preshared keys In-reply-to: Your message of "Mon, 13 Dec 1999 11:59:25 +0300." <003901bf4548$5cd22120$78253ac3@elvis.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26287.945111606.1@network-alchemy.com> Date: Mon, 13 Dec 1999 11:00:06 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 13 Dec 1999 11:59:25 +0300 you wrote > > > > What problem? It would help if you could say exactly what you're trying to > > solve. It started out as a way to not require keys to be bound to an IP > > address. But that problem is solved. So what is it that you're trying to > > solve now? > > I think the problem is to not require keys to be bound to an IP address > while using Main Mode. You solution doesn't solve this problem, while, > Hugo's does. And besides, Hugo's solution makes policy lookup in IKE > more uniform - you always rely only on ID payload content regardless of > IKE's mode of operation. That's not a problem, that's a feature request. What is the problem that not binding a pre-shared key to an IP address in Main Mode would solve? Would Base Mode with ID_KEY_ID-based pre-shared keys not solve that problem as well? Would RSA (or El-Gamal) encrypted nonces not solve that problem as well? Dan. From owner-ipsec@lists.tislabs.com Mon Dec 13 13:25:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13144; Mon, 13 Dec 1999 13:25:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23086 Mon, 13 Dec 1999 14:51:59 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0102D6CE@exchange> From: Andrew Krywaniuk To: francisco_corella@hp.com, dharkins@network-alchemy.com Cc: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: RE: A fix for main mode with preshared keys Date: Mon, 13 Dec 1999 12:15:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. Three comments. REDEFINITION OF SKEYID_E: As I see it, there are two problems: 1) Lack of identity protection in MM w/ preshared-keys. 2) Authentication is not confirmed in this case (such that it's difficult to distinguish between a key mismatch and an implementation error). I agree that Hugo's suggested redefinition of SKEYID_e solves both of these problems. In fact, it's essentially the same as what we discussed a few months ago. GENERALIZING ID_KEY_ID: I didn't say I didn't like the idea of ID_KEY_ID. I do. I just don't think it should be inextricably tied to the MM/shared case. Consider the current state of things: 1) MM/shared provides extra keymat entropy but no identity protection. 2) MM/sig provides identity protection against passive attacks. 3) ID_KEY_ID could provide extra keymat entropy and identity protection against active attacks. Why the discrepancy? Why not give both authentication methods the property of having identity protection against passive attacks? Then, for those of us who are truly paranoid, the ID_KEY_ID mechanism could be used to be used to provide extra protection with either authentication technique. It's the same reason why we wanted XAuth to be a phase 2 exchange, rather than part of phase 1 -- it allows you to choose the phase 1 authentication method you want to use, allow with its various strengths, weaknesses and idiosyncrasies. (Please don't restart the debate on the technical merits of XAuth -- I only mention this to illustrate how the various stages of authentication can be logically separated.) ID_KEY_ID RECOVERY: Also, I raised concerns about keeping a shared state with no recovery protection. I'm not just talking about cases where the HD crashes; it is easier than you think for the two peers to get out of synch. For example, say that A updates her state after she sends MM5. Then what if the physical connection is lost and B never receives MM5. Now the state is unsynchronized and the users cannot communicate. It doesn't matter if she waits until she receives MM6 before updating the state because MM6 could just as easily be lost. It's just like the problem we had with packet retransmission. You can never quite be sure that the final packet of an exchange has been received. I would suggest that if ID_KEY_ID is used then a recovery mechanism should be built in. For example, consider this technique (stateless ID_KEY_ID): 1) The client sends (nonce, hash). 2) The gateway checks if prf(key | nonce, id) == hash for each id in the list. 3) If prf matches for some id then the negotiation is allowed to proceed. 4) At the end of the negotiation, the client sends next_nonce. On subsequent negotiations (stateful ID_KEY_ID): 1) The client sends (nonce, hash). 2) The gateway looks for nonce in its hash_table. 3) If next_nonce matches, the gateway verifies that prf(key | nonce, id) == hash 4) If next_nonce does not match, the gateway checks the stateless case. This provides a built-in recovery mechanism, since a client that forgets its state (next_nonce) can fall back to using a random nonce. Also, if the gateway forgets its state, it can still authenticate the client using the stateless method. The first negotiation between the peers may use stateful ID_KEY_ID (if the state has been pre-seeded), stateless ID_KEY_ID (if the gateway has a list of all client ids), or simply regular main mode (in which case the identity will be divulged during the first connection but subsequent identity tracking attempts will fail). Note that stateless ID_KEY_ID is a DoS threat so the gateway might reject these connections while it is under heavy load. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: francisco_corella@hp.com [mailto:francisco_corella@hp.com] > Sent: Monday, December 13, 1999 12:22 AM > To: dharkins@network-alchemy.com > Cc: francisco_corella@hp.com; hugo@ee.technion.ac.il; > ipsec@lists.tislabs.com > Subject: Re: A fix for main mode with preshared keys > > > Dan, > > When I said that the ID_KEY_ID solution only seems to work > for keys shared > between two parties, I was referring to ID_KEY_ID with your > method for > preventing traffic analysis. Without it, ID_KEY_ID seems like a weak > mechanism for identity protection, especially given that the protocol > includes a DH exchange that allows you to provide proper > encryption for the > identities. > > The synchonization problem between two parties, when using > the method for > preventing traffic analysis, does not require a disk crash. > It can also > happen if there is a reboot due to a software error or power > failure or > anything else before the latest value of the key has been > written out to > secondary storage. This means that whenever there is an uncontrolled > reboot, an operator will have to manually resynchronize *all* > the preshared > keys in case one of them has become out of sync. > > The redefinition of SKEYID_e described by Hugo solves the > problem elegantly. If > adopted, it would also clarify the IKE protocol by removing > any need to rely on > source IP addresses in IP packets for identification instead > of relying on the > ID payload. > > Francisco > > ______________________________ Reply Separator > _________________________________ > Subject: Re: A fix for main mode with preshared keys > Author: Non-HP-dharkins (dharkins@network-alchemy.com) at > HP-ColSprings,mimegw5 > Date: 12/12/99 5:06 PM > > > ID_KEY_ID is just another way of identifying a pre-shared > key. If you > choose to not authenticate the peer and want to have a group > pre-shared > key there is nothing inheirent in ID_KEY_ID that would > prevent you from > doing this. > > There are no syncronization problems with using ID_KEY_ID > anymore than > there are with plain identified-by-ip-address pre-shared keys. The > problem came when I described a technique to prevent traffic analysis > (although I think that's not really an issue but it has been > raised in > the past as one so I felt I should address it) by hashing the > key _after_ > authentication. Now the problem Andrew described was > something along the > lines of "what happens if my hard drive crashes and I want to restore > my drive without re-syncronizing". But a security protocol is > not the place > to address these problems (after all what if you had a disk > crash and a > fire in the closet where your tapes were stored! This line of > reasoning > could go on forever and after all, backup tapes that contain > authentication > information should probably be stored in the central office so > resyncronization with the database is not an issue). On the > other hand, if > it's such a worry then don't rehash the ID_KEY_ID; it's not necessary. > > But if you can live with the scaling difficulties in pre-shared keys > then you can live with the scaling difficulties of uncertified public > keys and use RSA encryption mode (or El-Gamal encryption mode). You > get ID protection and all the rich negotiation of Main Mode. > > Dan. > > On Sun, 12 Dec 1999 16:17:01 PST you wrote > > > > Hugo, > > > > I like very much your solution based on redifining SKEYID_e. > > > > Concerning the ID_KEY_ID solution, if I understand it > correctly, it works whe > >n > > the key is shared between two parties only. It does not > work in the case whe > >re > > it is shared by multiple parties (e.g. all machines in a > given domain). And > >in > > the case of two parties, it has the synchronization > problems that were pointe > >d > > out by Andrew Krywaniuk. So I think the SKEYD_e solution > is much better. > > > > Francisco > From owner-ipsec@lists.tislabs.com Mon Dec 13 13:42:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13341; Mon, 13 Dec 1999 13:42:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23171 Mon, 13 Dec 1999 15:12:15 -0500 (EST) Message-Id: <199912132013.MAA26656@potassium.network-alchemy.com> To: Andrew Krywaniuk cc: francisco_corella@hp.com, hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: A fix for main mode with preshared keys In-reply-to: Your message of "Mon, 13 Dec 1999 12:15:44 EST." <319A1C5F94C8D11192DE00805FBBADDF0102D6CE@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26653.945115999.1@network-alchemy.com> Date: Mon, 13 Dec 1999 12:13:19 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 13 Dec 1999 12:15:44 EST you wrote > Hi all. Three comments. > > As I see it, there are two problems: > > 1) Lack of identity protection in MM w/ preshared-keys. Oh gimme a break. The same IP address is going to be used for the IPSec traffic so what sort of traffic analysis are you envisioning here? And Main Mode is not the only exchange to use and pre-shared keys are not the only authentication method to use. Any "problem" you have can be solved using existing mechanisms. > 2) Authentication is not confirmed in this case (such that it's difficult to > distinguish between a key mismatch and an implementation error). It's not difficult to determine the problem if you know what you're doing. Dan. From owner-ipsec@lists.tislabs.com Mon Dec 13 14:38:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13963; Mon, 13 Dec 1999 14:38:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23398 Mon, 13 Dec 1999 16:11:40 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0102D861@exchange> From: Andrew Krywaniuk To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: A fix for main mode with preshared keys Date: Mon, 13 Dec 1999 16:17:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 2) Authentication is not confirmed in this case (such that > it's difficult to > > distinguish between a key mismatch and an implementation error). > > It's not difficult to determine the problem if you know what > you're doing. Yeah. Unfortunately I'm an idiot because whenever I see Invalid Payload Type, Invalid Id Info, or Payload Malformed, I don't immediately think "Gee, must be a shared secret mismatch." Normally I only see this error when I change my test network configuration, and I usually change my configuration because I'm testing a new feature. So when I look for the cause of the error, my first instinct is that the new code is causing the error. Yes, I eventually realize that it's a shared secret mismatch, but it's frustrating as hell. When we ship our products, we have to put in a message box that says if you get one of those errors when processing the first encrypted message then it's probably a shared secret mismatch. It's an embarrassment and it's a kludge. What if we really do get a badly formed packet from the peer? Or what if the id info really is invalid? Then the customer is really going to get confused. Of course our gateways support certificates and most of our big customers have PKIs, but for various reasons we still have to support the pre-shared key case. Our policy description files allow you to mix and match. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Monday, December 13, 1999 3:13 PM > To: Andrew Krywaniuk > Cc: francisco_corella@hp.com; hugo@ee.technion.ac.il; > ipsec@lists.tislabs.com > Subject: Re: A fix for main mode with preshared keys > > > On Mon, 13 Dec 1999 12:15:44 EST you wrote > > Hi all. Three comments. > > > > As I see it, there are two problems: > > > > 1) Lack of identity protection in MM w/ preshared-keys. > > Oh gimme a break. The same IP address is going to be used for > the IPSec > traffic so what sort of traffic analysis are you envisioning here? > > And Main Mode is not the only exchange to use and pre-shared > keys are not > the only authentication method to use. Any "problem" you have can be > solved using existing mechanisms. > > > 2) Authentication is not confirmed in this case (such that > it's difficult to > > distinguish between a key mismatch and an implementation error). > > It's not difficult to determine the problem if you know what > you're doing. > > Dan. > From owner-ipsec@lists.tislabs.com Mon Dec 13 19:13:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA29812; Mon, 13 Dec 1999 19:13:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23950 Mon, 13 Dec 1999 20:15:53 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Mon, 13 Dec 1999 17:19:28 -0800 Message-Id: In-Reply-To: <199912130528.VAA24805@potassium.network-alchemy.com> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: dharkins@network-alchemy.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, See my comments below, marked *** Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE Author: Non-HP-dharkins (dharkins@Network-Alchemy.COM) at HP-ColSprings,mimegw5 Date: 12/12/99 9:28 PM On Sun, 12 Dec 1999 18:43:16 PST you wrote > The public key encryption methods for phase 1 authentication require the > initiator to know the public key of the responder, as explained in section > 6.1, 4th paragraph of the 5/99 draft. The responder does not have the > option to send its certificate as part of the change. This is unfortunate, > since there are cases where the initiator may have no other way of > obtaining the certificate, e.g. because a certificate repository is behind > a firewall. What problem are you trying to solve? This thread started because you wanted to use pre-shared keys in Main Mode and not have to bind that key to an IP address. *** This was intended as a new thread, not directly related to the thread concerning MM and preshared keys But in that case the initiator has to know the identity of the responder anyway so I'm not sure what's the hold-up here. *** You are right, I had forgotten about that. This can be fixed, however, if we adopt Hugo's redefinition of SKEYID_e. To avoid mixing the threads, I will describe the solution in a separate message, on the other thread (Note: cert- ificates are not required, these can be uncertified public keys which are distributed in the same fashion as your pre-shared keys). > A more serious problem, however, is that the initiator may not even know > the identity of the responder. This may seem odd, but it can easily happen > in cases where the initiator is a gateway acting as a proxy for a client. > Suppose the IP address of the responder as been assigned dynamically. The n> client may have learned this address in a previous exchange through the > same gateway or through a different gateway. The client may then send an IP > packet to this IP address, and this may cause the gateway to initiate an > IKE exchange with that IP address. In this situation, the gateway, which > is the initiator of the IKE exchange, knows the dynamically assigned IP > address but may not know the "real" identity of the responder, the identity > that determines the public key. Hmmm. A gateway which has policy to an identity which it does no know. That sounds like a bogus policy right there. Forget IKE. How would you express "I want to protect packets from 'host X' to 'somewhere interesting'" if you can't know the identity of "somewhere interesting" a priori!? How would you know what to protect in that case? It doesn't seem you would. So an invalid policy which cannot be expressed in IKE doesn't seem like a problem. *** THE GATEWAY DOES KNOW THE IDENTITY OF THE RESPONDER, AND HAS A POLCY BASED ON THAT KNOWN IDENTITY Let me try to explain the scenario in more detail. The gateway is at the edge of the intranet of a corporation, let's call it HiTech, Inc. The gateway is negotiating on behalf of a client. The client is a host inside the intranet. The client wants to communicate with the laptop of the employee John Smith. This employee is travelling and is currently connected to the Internet through an ISP which has no relation to hitech.com. The ISP has dynamically assigned the IP address 11.22.33.44 to the laptop of John Smith. The client has learned this IP address through a previous exchange, that may have gone through the same or a different gateway. The client sends an IP packet to 11.22.33.44. The gateway does not have a policy for this IP address. However, the gateway initiates an IKE exchange with 11.22.33.44 on behalf of the client, and as part of this exchange the laptop identifies itself as John Smith's laptop by sending the distinguished name "CN=John Smith; O=Hitech, Inc; C=US" in the ID payload. Now the gateway knows who it is talking too, and can look up the appropriate policy based on the distinguished name. > It should be possible to fix these two problems, probably at the expense of > additional messages, by first establishing the DH secret, then exchanging > identities and optional certificates encrypted under a symmetric key > derived from the DH secret, then exchanging the nonces encrypted under the > public keys of the parties. What problems? You want to have a way to not bind a key to an IP address. Fine, use uncertified public keys. Then you want to have policy to a wildcard. Sorry, but things just don't work that way, and that has nothing to do with IKE. Dan. From owner-ipsec@lists.tislabs.com Mon Dec 13 20:25:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07963; Mon, 13 Dec 1999 20:25:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24281 Mon, 13 Dec 1999 22:00:37 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Mon, 13 Dec 1999 19:04:11 -0800 Message-Id: In-Reply-To: <199912131459.QAA27116@torni.ssh.fi> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 TO: kivinen@ssh.fi CC: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="A" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I thought one reason for having both signatures and public key encryption as authentication methods is that signatures provide non-repudiability while public key encryption provides repudiability. In some cases you may want one, and in some cases the other. Also, public key provides stronger security because an attacker would have to break both DH and RSA to obtain the key material derived from the exchange. With signatures the attacker only needs to break DH. (Granted, this may be good enough.) It would be nice to be able to enjoy the benefits of the public key encryption method even in cases where the initiator does not know the public key of the responder at the beginning of the exchange. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE Author: Non-HP-kivinen (kivinen@ssh.fi) at HP-ColSprings,mimegw5 Date: 12/13/99 6:59 AM francisco_corella@hp.com writes: > It should be possible to fix these two problems, probably at the expense of > additional messages, by first establishing the DH secret, then exchanging Use signatures based authentication method, instead of rsa encryption. There IS a reason why we have different types of authentications in the IKE. They offer little bit different things... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Dec 13 20:25:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07993; Mon, 13 Dec 1999 20:25:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24323 Mon, 13 Dec 1999 22:20:57 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Mon, 13 Dec 1999 19:24:30 -0800 Message-Id: In-Reply-To: <9912131653.AA24058@secpwr.watson.ibm.com> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: pau@watson.ibm.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pau-Chen, See my comments below, marked *** Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE Author: Non-HP-pau (pau@watson.ibm.com) at HP-ColSprings,mimegw5 Date: 12/13/99 8:53 AM On 12 Dec 1999 18:43:16 -0800, francisco_corella@hp.com wrote : > The public key encryption methods for phase 1 authentication require the > initiator to know the public key of the responder, as explained in section > 6.1, 4th paragraph of the 5/99 draft. The responder does not have the > option to send its certificate as part of the change. This is unfortunate, > since there are cases where the initiator may have no other way of > obtaining the certificate, e.g. because a certificate repository is behind > a firewall. Francisco : I am one of the co-authors of the original pk-encryption mode draft; and indeed it was assumed that initiator knows the responder's public key when it starts the IKE negotiation. But this is really not a bug of IKE or pk-encryption mode. IMHO, the problem we have today is that there is a big gap between the internet names (IP addresses, DNS names, ...) used in IKE and the (would-be) directory structure (X500) used to search the certificates. In general, one cannot search a X509 certificate by a DNS name or an IP address. Using DNSSEC and Dynamic DNS would solve the problem, sadly the deployment is not there yet. *** By the simple expedient of having the parties provide their certificates you can remove the dependency of IPSEC on these other deployments. > > A more serious problem, however, is that the initiator may not even know > the identity of the responder. This may seem odd, but it can easily happen > in cases where the initiator is a gateway acting as a proxy for a client. > Suppose the IP address of the responder as been assigned dynamically. The > client may have learned this address in a previous exchange through the > same gateway or through a different gateway. The client may then send an IP > packet to this IP address, and this may cause the gateway to initiate an > IKE exchange with that IP address. In this situation, the gateway, which > is the initiator of the IKE exchange, knows the dynamically assigned IP > address but may not know the "real" identity of the responder, the identity > that determines the public key. You can use signature mode with in-line certificates in this case. If the remote host cannot produce its certificate and signature, then most likely pk-encryption mode cannot be used neither. I must agree with Dan that the gateway will still have a hard time in determining what to do with a remote host of which the gateway knows nothing. *** Hopefully the more detailed scenario that I provided in an earlier message has cleared this objection. The gateway may not be familiar with the dynamically assigned IP address of the responder, but may be familiar with some other form of identity submitted by the responder (in the ID payload) during the exchange. > > It should be possible to fix these two problems, probably at the expense of > additional messages, by first establishing the DH secret, then exchanging > identities and optional certificates encrypted under a symmetric key > derived from the DH secret, then exchanging the nonces encrypted under the > public keys of the parties. IMHO, IKE should really not be twisted for every conceivable authentication/application scenarios. Then it would go down the tube as many OSI protocols, they have a little something for everyone but becomes too heavy for anyone. I personally think IKE and IPSEC are meant to provide the basic communication security, any finer-grain or more sophisticated authentication can be built on top with added ease and security assurance; but we don't have to change IKE to get all those. *** I would agree with that, but then why have two forms of public key encryption in addition to digital signatures and preshared keys? If we do have support public key encryption, we may as well make it as broadly applicable as possible. Pau-Chen > > Francisco > > (francisco_corella@hp.com) > From owner-ipsec@lists.tislabs.com Mon Dec 13 20:54:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10418; Mon, 13 Dec 1999 20:54:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24384 Mon, 13 Dec 1999 22:51:18 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Mon, 13 Dec 1999 19:54:54 -0800 Message-Id: In-Reply-To: <199912132013.MAA26656@potassium.network-alchemy.com> Subject: Re: A fix for main mode with preshared keys MIME-Version: 1.0 To: dharkins@network-alchemy.com Cc: francisco_corella@hp.com, akrywaniuk@TimeStep.com, hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See comment below, marked *** ______________________________ Reply Separator _________________________________ Subject: Re: A fix for main mode with preshared keys Author: Non-HP-dharkins (dharkins@Network-Alchemy.COM) at HP-ColSprings,mimegw5 Date: 12/13/99 12:13 PM On Mon, 13 Dec 1999 12:15:44 EST you wrote > Hi all. Three comments. > > As I see it, there are two problems: > > 1) Lack of identity protection in MM w/ preshared-keys. Oh gimme a break. The same IP address is going to be used for the IPSec traffic so what sort of traffic analysis are you envisioning here? And Main Mode is not the only exchange to use and pre-shared keys are not the only authentication method to use. Any "problem" you have can be solved using existing mechanisms. *** Isn't Main Mode with preshared keys the only *required* exchange? > 2) Authentication is not confirmed in this case (such that it's difficult to > distinguish between a key mismatch and an implementation error). It's not difficult to determine the problem if you know what you're doing. Dan. From owner-ipsec@lists.tislabs.com Mon Dec 13 21:59:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13915; Mon, 13 Dec 1999 21:59:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA24367 Mon, 13 Dec 1999 22:44:39 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Mon, 13 Dec 1999 19:48:13 -0800 Message-Id: In-Reply-To: <199912131900.LAA26290@potassium.network-alchemy.com> Subject: Re: A fix for main mode with preshared keys MIME-Version: 1.0 To: dharkins@network-alchemy.com Cc: ipsec@lists.tislabs.com, svan@trustworks.com Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If nothing else, the confusion caused by having both the id payload and the source ip address as possible ways of determmining the identity is a big problem, which results in bugs and lack of interoperability. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A fix for main mode with preshared keys Author: Non-HP-dharkins (dharkins@network-alchemy.com) at HP-ColSprings,mimegw5 Date: 12/13/99 11:00 AM On Mon, 13 Dec 1999 11:59:25 +0300 you wrote > > > > What problem? It would help if you could say exactly what you're trying to > > solve. It started out as a way to not require keys to be bound to an IP > > address. But that problem is solved. So what is it that you're trying to > > solve now? > > I think the problem is to not require keys to be bound to an IP address > while using Main Mode. You solution doesn't solve this problem, while, > Hugo's does. And besides, Hugo's solution makes policy lookup in IKE > more uniform - you always rely only on ID payload content regardless of > IKE's mode of operation. That's not a problem, that's a feature request. What is the problem that not binding a pre-shared key to an IP address in Main Mode would solve? Would Base Mode with ID_KEY_ID-based pre-shared keys not solve that problem as well? Would RSA (or El-Gamal) encrypted nonces not solve that problem as well? Dan. From owner-ipsec@lists.tislabs.com Tue Dec 14 00:54:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA20886; Tue, 14 Dec 1999 00:54:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA24730 Tue, 14 Dec 1999 02:34:01 -0500 (EST) From: "Josef Pojsl" Date: Tue, 14 Dec 1999 08:42:19 +0100 To: ipsec@lists.tislabs.com Subject: PGP keys in IKE Message-ID: <19991214084219.D12657@regent.in.skynet.cz> Mail-Followup-To: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, please forgive me if my question has been asked here (but I have been listening for a couple of weeks now and it has not): NAI included in their IKE implementation (PGPnet) the ability to authenticate through PGP keys as an alternative to X.509 ceritificates. AFAIK, the RFCs do not mention PGP keys and specify only X.509 authentication. Is there any effort to give out a standard for PGP authentication in IKE? Thanks in advance for any comments. Josef -- Josef Pojsl mailto:josef.pojsl@skynet.cz SkyNet, a.s. NAI Security Partner PGP fingerprint: 23CB DE28 51A9 53F1 0C1F 67EF B3ED 8435 9D1B C7C8 From owner-ipsec@lists.tislabs.com Tue Dec 14 07:24:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28474; Tue, 14 Dec 1999 07:24:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25972 Tue, 14 Dec 1999 08:51:17 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Tue, 14 Dec 1999 05:54:47 -0800 Message-Id: Subject: Re: A fix for main mode with preshared keys MIME-Version: 1.0 TO: ipsec@lists.tislabs.com Content-Type: text/plain; charset=US-ASCII; name="cc:Mail" Content-Disposition: inline; filename="cc:Mail" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One additional remark. Dan Harkins reminded me of the following (in the pk encryption thread). Even if SKEYID_e is redefined as discussed, the initiator of a main mode exchange with preshared keys still needs to know the identity of the responder before it has received IDir. This is because it needs to compute HASH_I in the fifth message, and HASH_I is computed using SKEYID, which in turn is computed using the preshared key. The preshared key *must* be used in the computation of HASH_I, since this is what provides the proof that the initiator knows the preshared key. IKE knows the IP address of the responder, but there are scenarios where this may not be a "meaningful" form of identity, and where IKE has no access to a more meaningful form of identity before it receives IDir. I described one such scenario, involving a dynamically assigned IP address, in the pk encryption thread. Another scenario could be constructed in the case where the responder is a multihomed port. There is also the possibility that a meaningful form identity is simply not passed to IKE by the software that requests the IKE exchange. This difficulty could be resolved by changing main mode with preshared keys from Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R to Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr, IDir* HDR*, IDii, HASH_I --> <-- HDR*, HASH_R where IDir* is IDir with its body (excluding the "generic payload header") encrypted under SKEYID_e, which is itself redefined as discussed. Francisco (francisco_corella@hp.com) From owner-ipsec@lists.tislabs.com Tue Dec 14 08:27:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29817; Tue, 14 Dec 1999 08:27:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26342 Tue, 14 Dec 1999 10:00:59 -0500 (EST) Date: Tue, 14 Dec 1999 17:04:09 +0200 (IST) From: Hugo Krawczyk Reply-To: Hugo Krawczyk To: ipsec list Subject: Re: A fix for main mode with preshared keys Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a clarification after getting some private email messages regarding this issue. When I suggested a way to decouple the calculation of SKEYID_e from the value of the pre-shared key I was only improving on other people's suggestion. I do NOT recommend doing this change to IKE. BTW, people complain about the complexity of IKE and at the same time request new features. These two demands do not work together... Hugo From owner-ipsec@lists.tislabs.com Tue Dec 14 09:17:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00834; Tue, 14 Dec 1999 09:17:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26372 Tue, 14 Dec 1999 10:04:20 -0500 (EST) Message-Id: <199912141507.KAA00146@istari.sandelman.ottawa.on.ca> To: "Josef Pojsl" CC: ipsec@lists.tislabs.com Subject: Re: PGP keys in IKE In-Reply-To: Your message of "Tue, 14 Dec 1999 08:42:19 +0100." <19991214084219.D12657@regent.in.skynet.cz> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 14 Dec 1999 10:07:51 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The word "PGP" appears 5 times in RFC2408. Most specifically, it appears in section 3.9 "Certificate Payload" Certificate Type Value NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 RESERVED 11 - 255 From owner-ipsec@lists.tislabs.com Tue Dec 14 12:28:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03818; Tue, 14 Dec 1999 12:28:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27167 Tue, 14 Dec 1999 13:41:24 -0500 (EST) Message-ID: <38569018.952178E8@cyphers.net> Date: Tue, 14 Dec 1999 10:44:53 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Josef Pojsl CC: ipsec@lists.tislabs.com Subject: Re: PGP keys in IKE References: <19991214084219.D12657@regent.in.skynet.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been meaning to document what we did in a draft, but haven't gotten around to it. It really is pretty simple, and as Michael Richardson noted the ISAKMP draft does in fact cover the IDs used for PGP in IKE. Beyond that, the only things left to document for this are essentially: * PGP keys are included in the CERT payload with the appropriate ID from ISAKMP, and the format of those keys is the standard OpenPGP binary key format from RFC 2440. In other words, don't ASCII-armor the key. * Certificate chains are less relevant because all relevant signatures are included on the OpenPGP key. Depending on policy, you could include a specific chain of trusted introducers based on the primary meta-introducer as the root for a cert chain. * It is recommended that a Certificate Request payload be sent with the PGP identifier so as to make sure there is no confusion over certificate types. With the imminent advent of DNS keys in IKE and some people using X.509 now, I think this is going to be important for all implementations. * PGPnet is a VPN client, therefore we don't want to make it necessary that a particular user have a fixed IP address. If one were to make a gateway product that supported PGP keys, one would want to use a PGP key that includes the IP address of the device. To do that, or to include the DNS name in a PGP key, use an attribute user ID (a la photo IDs) defined for that purpose. * The Phase 1 ID must be (regardless of whether you are using PGP or X.509 or ...) based from the certificate. In the case of PGP, it must be the primary user ID. Josef Pojsl wrote: > > Hello, > > please forgive me if my question has been asked here (but I have > been listening for a couple of weeks now and it has not): > > NAI included in their IKE implementation (PGPnet) the ability > to authenticate through PGP keys as an alternative to X.509 > ceritificates. AFAIK, the RFCs do not mention PGP keys and specify > only X.509 authentication. Is there any effort to give out > a standard for PGP authentication in IKE? > > Thanks in advance for any comments. > > Josef > > -- > Josef Pojsl mailto:josef.pojsl@skynet.cz > SkyNet, a.s. NAI Security Partner > PGP fingerprint: 23CB DE28 51A9 53F1 0C1F 67EF B3ED 8435 9D1B C7C8 - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBOFaPXqy7FkvPc+xMEQJjEQCg42U1/v30tISySr+pLVOIqDfm9BcAn3QL WQ0oj5bLmzXyDp40blA2sINm =srMy -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Dec 14 12:45:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA04193; Tue, 14 Dec 1999 12:45:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27332 Tue, 14 Dec 1999 14:07:45 -0500 (EST) From: pau@watson.ibm.com Date: Tue, 14 Dec 1999 14:11:43 -0500 Message-Id: <9912141911.AA24012@secpwr.watson.ibm.com> To: francisco_corella@hp.com Subject: Re: A problem with public key encrption in IKE Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: ebDUIwpo5EbNtl73hbnw4A== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francisco, please see my comments below Regards, Pau-Chen ------------------------------------------------------------------ On Tue Dec 14 11:36:48 1999, francisco_corella@hp.com wrote > > Pau-Chen, > > See my comments below, marked *** > > Francisco > > > ______________________________ Reply Separator ____________________________ > Subject: Re: A problem with public key encrption in IKE > Author: Non-HP-pau (pau@watson.ibm.com) at HP-ColSprings,mimegw5 > Date: 12/13/99 8:53 AM > > > > > > > On 12 Dec 1999 18:43:16 -0800, francisco_corella@hp.com wrote : > > > The public key encryption methods for phase 1 authentication require the > > initiator to know the public key of the responder, as explained in section > > 6.1, 4th paragraph of the 5/99 draft. The responder does not have the > > option to send its certificate as part of the change. This is unfortunate, > > since there are cases where the initiator may have no other way of > > obtaining the certificate, e.g. because a certificate repository is behind > > a firewall. > > Francisco : > > I am one of the co-authors of the original pk-encryption mode draft; > and indeed it was assumed that initiator knows the responder's public key > when it starts the IKE negotiation. But this is really not a bug of > IKE or pk-encryption mode. > > IMHO, the problem we have today is that there is a big gap between the > internet names (IP addresses, DNS names, ...) used in IKE and the > (would-be) directory structure (X500) used to search the certificates. > In general, one cannot search a X509 certificate by a DNS name or an IP > address. Using DNSSEC and Dynamic DNS would solve the problem, sadly > the deployment is not there yet. > > *** By the simple expedient of having the parties provide their > certificates you can remove the dependency of IPSEC on these > other deployments. Please see my comments below. > > > > > A more serious problem, however, is that the initiator may not even know > > the identity of the responder. This may seem odd, but it can easily happen > > in cases where the initiator is a gateway acting as a proxy for a client. > > Suppose the IP address of the responder as been assigned dynamically. The > > client may have learned this address in a previous exchange through the > > same gateway or through a different gateway. The client may then send an IP > > packet to this IP address, and this may cause the gateway to initiate an > > IKE exchange with that IP address. In this situation, the gateway, which > > is the initiator of the IKE exchange, knows the dynamically assigned IP > > address but may not know the "real" identity of the responder, the identity > > that determines the public key. > > You can use signature mode with in-line certificates in this case. > If the remote host cannot produce its certificate and signature, > then most likely pk-encryption mode cannot be used neither. > > I must agree with Dan that the gateway will still have a hard time in > determining what to do with a remote host of which the gateway knows > nothing. > > *** Hopefully the more detailed scenario that I provided in an > earlier message has cleared this objection. The gateway may not > be familiar with the dynamically assigned IP address of the > responder, but may be familiar with some other form of identity > submitted by the responder (in the ID payload) during the > exchange. I think you may have a point here. But if I understand your scenario correctly, the gateway has to initiate the IKE exchange with the remote host of which the gateway knows nothing. So the gateway may have difficulty in determining what to propose. Of course, a catch-all wildcard entry in the gateway's policy may solve the problem; but I am not too sure about the wildcard's security implication. > > > > > It should be possible to fix these two problems, probably at the expense of > > additional messages, by first establishing the DH secret, then exchanging > > identities and optional certificates encrypted under a symmetric key > > derived from the DH secret, then exchanging the nonces encrypted under the > > public keys of the parties. > > IMHO, IKE should really not be twisted for every conceivable > authentication/application scenarios. Then it would go down the > tube as many OSI protocols, they have a little something for > everyone but becomes too heavy for anyone. I personally think IKE and > IPSEC are meant to provide the basic communication security, > any finer-grain or more sophisticated authentication can be built > on top with added ease and security assurance; but we don't have to > change IKE to get all those. > > *** I would agree with that, but then why have two forms of > public key encryption in addition to digital signatures and > preshared keys? If we do have support public key > encryption, we may as well make it as broadly applicable as > possible. > Having two forms of public key encryption modes came from some miscommunication we (I, Hugo and Ran) had with Dan. As for your proposed solution, the problems I have with it are : 1. It introduces yet another new exchange type into ISAKMP. 2. An initiator or a responder may be revealing its ID to an unknown party. The publick-key modes, as they are now, do not have this problem. > > Pau-Chen > > > > > Francisco > > > > (francisco_corella@hp.com) > > > > From owner-ipsec@lists.tislabs.com Tue Dec 14 13:30:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04790; Tue, 14 Dec 1999 13:30:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27636 Tue, 14 Dec 1999 15:07:18 -0500 (EST) Message-ID: <3856A444.340C3A46@redcreek.com> Date: Tue, 14 Dec 1999 12:10:44 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: fqdn and trailing dot in IDs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy () So when we use a FQDN as a name to Identify an endpoint, do we require and/or enforce that the 'trailing dot' be applied? An FQDN without a trailing dot is ambigous as pointed out by rfc1912 sect 3.2 (exerpt below) Always remember your $ORIGIN. If you don't put a `.' at the end of an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then the nameserver will append $ORIGIN to the name. Double check, triple check, those trailing dots, especially in in-addr.arpa zone files, where they are needed the most. If we follow the 'robustness' principle and try to say that we always send with a trailing dot but accept without a trailing dot, then certianly we would run into trouble hashing over the IDs in the Phase 2 negotiation. If we follow the 'let the user deal with it' principle, and try to say "the user must make the ID string be the same on both ends but we don't really care if it has a trailing dot or not as long as it matches", then sometimes a non-trailing dot form will be used. In this case, after we suceed the negotiation, we will have some ambiguity in which packets match our FQDN rule. If we follow the 'big brogher knows best' principle and always tag on a trailing dot for the administrator if they 'forgot' it, then this may need to be a clearly specified MUST behaviour in the RFCs for it to be interoperable. What do y'all think? I vote for enforcing the placement of a trailing dot. I also note that the example in rfc2401 of fqdn does not have a trailing dot. This simple fact will lend a strong argument to the 'let the user deal with it' system and just accepting the small abiguity in the name. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### end Howdy; From owner-ipsec@lists.tislabs.com Tue Dec 14 14:08:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05310; Tue, 14 Dec 1999 14:08:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27728 Tue, 14 Dec 1999 15:49:03 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 14 Dec 1999 15:38:07 -0500 To: francisco_corella@hp.com From: Stephen Kent Subject: Re: A problem with public key encrption in IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francisco, Whether a signature provides a basis for non-repudiation depends on the details of the generation process. Note that in the case of IPsec, at most one might be able to prove that a peer initiated an SA, but the signature applied during the IKE exchange would not say anything about what data was sent on the SAs later. So, while I like the use of signatures for IKE authentication, I would not argue too strongly for them based on any non-repudiation basis. Steve From owner-ipsec@lists.tislabs.com Tue Dec 14 15:06:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05876; Tue, 14 Dec 1999 15:06:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27816 Tue, 14 Dec 1999 16:30:18 -0500 (EST) Date: Tue, 14 Dec 1999 23:34:04 +0200 (EET) Message-Id: <199912142134.XAA12747@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: wprice@cyphers.net Cc: Josef Pojsl , ipsec@lists.tislabs.com Subject: Re: PGP keys in IKE In-Reply-To: <38569018.952178E8@cyphers.net> References: <19991214084219.D12657@regent.in.skynet.cz> <38569018.952178E8@cyphers.net> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will Price writes: > * It is recommended that a Certificate Request payload be sent with > the PGP identifier so as to make sure there is no confusion over > certificate types. With the imminent advent of DNS keys in IKE and > some people using X.509 now, I think this is going to be important > for all implementations. What is the contents of the certificate request, i.e. what does the certificate authority field contain, and in what format? Empty? > * The Phase 1 ID must be (regardless of whether you are using PGP or > X.509 or ...) based from the certificate. In the case of PGP, it > must be the primary user ID. What identity type you are using? ID_USER_FQDN? But that cannot contain the comment field that is usually present in the pgp-keys ("Tero Kivinen "), it can only contain "kivinen@ssh.fi". Actually the definition in the DOI says "fully-qualified username string", so I am not sure if it can contain comment fields also... Another possibility could be the ID_KEY_ID with the key binary key ID of the pgp key. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Dec 14 15:33:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06509; Tue, 14 Dec 1999 15:33:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27896 Tue, 14 Dec 1999 16:55:47 -0500 (EST) Message-Id: <4.2.1.19991214133943.00cdb880@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 14 Dec 1999 13:59:58 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: fqdn and trailing dot in IDs In-Reply-To: <3856A444.340C3A46@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:10 PM 12/14/99 -0800, Ricky Charlet wrote: >Howdy () > > So when we use a FQDN as a name to Identify an endpoint, do we > require >and/or enforce that the 'trailing dot' be applied? I certainly hope not. To the best of my understanding, that's only used in DNS server configuration. You quote from RFC 1912, which is an informational RFC that is mostly about avoiding common errors in BIND. The errors it refers to deal with partial domain names. We don't have those in IPsec. If someone has an ID that is of type FQDN and its value is "frodo", it is an error. The "F" really means something here. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Dec 14 15:36:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06576; Tue, 14 Dec 1999 15:36:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27928 Tue, 14 Dec 1999 17:03:21 -0500 (EST) Date: Wed, 15 Dec 1999 00:07:08 +0200 (EET) Message-Id: <199912142207.AAA24637@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Ricky Charlet Cc: ipsec Subject: fqdn and trailing dot in IDs In-Reply-To: <3856A444.340C3A46@redcreek.com> References: <3856A444.340C3A46@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 25 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet writes: > So when we use a FQDN as a name to Identify an endpoint, do we require > and/or enforce that the 'trailing dot' be applied? No, you never put that trailing dot to the FQDN in the IKE. The DOI says: ---------------------------------------------------------------------- 4.6.2.3 ID_FQDN The ID_FQDN type specifies a fully-qualified domain name string. An example of a ID_FQDN is, "foo.bar.com". The string should not contain any terminators. ---------------------------------------------------------------------- So it does not contain any terminators (no nul character, no dots). > An FQDN without a trailing dot is ambigous as pointed out by rfc1912 > sect 3.2 (exerpt below) In the DNS world FQDN is defined to contain the dot, but I general FQDN is just a domain name that identifies the name completely, i.e. include all parts of. From the RFC1594/FYI4 (FYI Q/A - for New Internet Users): ---------------------------------------------------------------------- 5.2 What is a Fully Qualified Domain Name? A Fully Qualified Domain Name (FQDN) is a domain name that includes all higher level domains relevant to the entity named. If you think of the DNS as a tree-structure with each node having its own label, a Fully Qualified Domain Name for a specific node would be its label followed by the labels of all the other nodes between it and the root of the tree. For example, for a host, a FQDN would include the string that identifies the particular host, plus all domains of which the host is a part up to and including the top-level domain (the root domain is always null). For example, atlas.arc.nasa.gov is a Fully Qualified Domain Name for the host at 128.102.128.50. In addition, arc.nasa.gov is the FQDN for the Ames Research Center (ARC) domain under nasa.gov. ---------------------------------------------------------------------- That entry seems to have disappeared in the later version of the FYI4, I don't know why... -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Dec 14 16:00:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06901; Tue, 14 Dec 1999 16:00:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27954 Tue, 14 Dec 1999 17:08:13 -0500 (EST) Date: Tue, 14 Dec 1999 17:11:44 -0500 Message-Id: <199912142211.RAA26079@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kivinen@ssh.fi Cc: wprice@cyphers.net, ipsec@lists.tislabs.com Subject: Re: PGP keys in IKE References: <19991214084219.D12657@regent.in.skynet.cz> <38569018.952178E8@cyphers.net> <199912142134.XAA12747@torni.ssh.fi> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: Tero> Another possibility could be the ID_KEY_ID with the key binary Tero> key ID of the pgp key. Or, if it's longer, it could be the fingerprint. (There are occasional key ID clashes; key fingerprint clashes are extremely unlikely.) paul From owner-ipsec@lists.tislabs.com Tue Dec 14 17:09:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07800; Tue, 14 Dec 1999 17:09:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28176 Tue, 14 Dec 1999 18:45:07 -0500 (EST) Message-ID: <3856D756.4D926405@redcreek.com> Date: Tue, 14 Dec 1999 15:48:38 -0800 From: Ricky Charlet Organization: RedCreek Communications Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: ipsec Subject: Re: fqdn and trailing dot in IDs References: <3856A444.340C3A46@redcreek.com> <199912142207.AAA24637@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > > Ricky Charlet writes: > > So when we use a FQDN as a name to Identify an endpoint, do we require > > and/or enforce that the 'trailing dot' be applied? > > No, you never put that trailing dot to the FQDN in the IKE. The DOI > says: > ---------------------------------------------------------------------- > 4.6.2.3 ID_FQDN > > The ID_FQDN type specifies a fully-qualified domain name string. An > example of a ID_FQDN is, "foo.bar.com". The string should not > contain any terminators. > ---------------------------------------------------------------------- Well alrighty then! That is about as clear as it gets and I'm sorry I missed it before I posted. -- #################################### # Ricky Charlet # (510) 795-6903 # rcharlet@redcreek.com #################################### From owner-ipsec@lists.tislabs.com Tue Dec 14 22:21:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12461; Tue, 14 Dec 1999 22:21:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA28660 Tue, 14 Dec 1999 23:50:44 -0500 (EST) Message-ID: <38571EF0.E17C5060@cyphers.net> Date: Tue, 14 Dec 1999 20:54:22 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tero Kivinen CC: Josef Pojsl , ipsec@lists.tislabs.com Subject: Re: PGP keys in IKE References: <19991214084219.D12657@regent.in.skynet.cz> <38569018.952178E8@cyphers.net> <199912142134.XAA12747@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tero Kivinen wrote: > > Will Price writes: > > * It is recommended that a Certificate Request payload be sent > > with the PGP identifier so as to make sure there is no confusion > > over certificate types. With the imminent advent of DNS keys in > > IKE and some people using X.509 now, I think this is going to be > > important for all implementations. > > What is the contents of the certificate request, i.e. what does the > certificate authority field contain, and in what format? Empty? I think the right thing to put here is the fingerprint of a particular PGP CA Key that is desired. We don't currently use this. > > * The Phase 1 ID must be (regardless of whether you are using PGP > > or X.509 or ...) based from the certificate. In the case of PGP, > > it must be the primary user ID. > > What identity type you are using? ID_USER_FQDN? But that cannot > contain the comment field that is usually present in the pgp-keys > ("Tero Kivinen "), it can only contain > "kivinen@ssh.fi". Actually the definition in the DOI says > "fully-qualified username string", so I am not sure if it can > contain comment fields also... > > Another possibility could be the ID_KEY_ID with the key binary key > ID of the pgp key. Yes, we currently use ID_KEY_ID with the full 20 byte fingerprint of the key as the Phase 1 ID. Has nothing to do with the primary user ID as I had mistakenly stated in my last message. Note that the term "KeyID" as used in OpenPGP parlance is really just a subset of the fingerprint bytes. I should really write this up. - -- Will Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBOFce66y7FkvPc+xMEQLCNQCg96FBt6opLbvf4tiMeduFCXoJ5D8AniSJ eX9n8CxxMI0p+WvGtAOeitPe =LV9h -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Dec 15 03:13:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA19169; Wed, 15 Dec 1999 03:13:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29232 Wed, 15 Dec 1999 04:50:31 -0500 (EST) Date: Wed, 15 Dec 1999 11:53:38 +0200 (IST) From: Hugo Krawczyk To: pau@watson.ibm.com cc: ipsec list Subject: Re: A problem with public key encrption in IKE In-Reply-To: <9912141911.AA24012@secpwr.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pau, > Having two forms of public key encryption modes came from some > miscommunication we (I, Hugo and Ran) had with Dan. these two modes are NOT the result of miscommunication with Dan. The original mode was taken by Dan from the Oakley draft which was Hilarie's implementation of the PK encryption mode of SKEME. The revised mode is more in line with what I had in mind when designing SKEME. Especially, the fact that it uses a single costly encryption-decryption operation at each party rather than two. Hugo From owner-ipsec@lists.tislabs.com Wed Dec 15 05:01:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21093; Wed, 15 Dec 1999 05:01:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA29382 Wed, 15 Dec 1999 06:51:33 -0500 (EST) Message-Id: <199912151155.GAA29646@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-pki-req-04.txt Date: Wed, 15 Dec 1999 06:55:16 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A PKIX Profile for IKE Author(s) : R. Thayer, C. Kunzinger, P. Hoffman Filename : draft-ietf-ipsec-pki-req-04.txt Pages : 28 Date : 14-Dec-99 The IKE protocol allows the use of the PKIX profile of X.509v3 certificates for encryption and authentication. Common practice in the IPsec community differs in some ways from these specifications made in the PKIX format specification and other specifications that have come from the PKIX WG. In order to promote interoperability in the IPsec market, this document lays out a profile for using PKIX in IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-pki-req-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-pki-req-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991214132947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-req-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991214132947.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Dec 15 05:06:10 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21439; Wed, 15 Dec 1999 05:06:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA29341 Wed, 15 Dec 1999 06:38:54 -0500 (EST) Date: Wed, 15 Dec 1999 13:42:58 +0200 (EET) From: Arne Ansper To: ipsec@lists.tislabs.com Subject: security gateways with different policies Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi! i'm trying to understand how negotiation of SA granularity is supposed to work. suppose we have two security gateways with different policies in their SPDs. first gateway has single rule which says that it must apply IPSec processing to all packets and that SA selector is copied from SPD. second gateway has single rule which says that it must apply IPSec processing and that SA selector is copied from packet. first gateway wants to use single SA for all traffic and second one wants to use different SA for every TCP connection/UDP packet. gateways use IKE for SA setup. how does the Quick Exchange look like when the first gateway is initiator and when second gateway is initiator? what are the IDui and IDur? can the responder change IDs sent by initiator or not? when the second gateway is initiator and sends IDui, IDur which specify single TCP connection, can the first gateway accept it even if it's SPD wants to use single SA for all traffic? arne From owner-ipsec@lists.tislabs.com Wed Dec 15 10:58:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15247; Wed, 15 Dec 1999 10:58:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00486 Wed, 15 Dec 1999 12:12:31 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Wed, 15 Dec 1999 09:14:47 -0800 Message-Id: In-Reply-To: <9912141911.AA24012@secpwr.watson.ibm.com> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: pau@watson.ibm.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pau-Chen, << I think you may have a point here. But if I understand your scenario correctly, the gateway has to initiate the IKE exchange with the remote host of which the gateway knows nothing. So the gateway may have difficulty in determining what to propose. Of course, a catch-all wildcard entry in the gateway's policy may solve the problem; but I am not too sure about the wildcard's security implication. >> Well, let's think about this... It seems that IPSEC implementations select the protection requirements (what they will propose/accept) for phase 1 and phase 2 together, based on the identity of the peer. I don't know if this is required by one of the RFCs, or if that's just the way it's done. It would make sense, though, to determine the protection requirements for each phase separately. The protection requirements for phase 1 could be determined independently of the identity of the peer. (After all, one purpose of phase 1 is to determine the identity of the peer.) The phase 1 requirements would not be specified by the SPD, they would be selected by the IPSEC administrator by means that need not be part of the IPSEC standard. Then the protection requirements for phase 2 could be determined based on the identity of the peer established in phase 1. These requirments would be specified by the SPD. Is this allowed by the RFCs? Francisco From owner-ipsec@lists.tislabs.com Wed Dec 15 10:58:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15261; Wed, 15 Dec 1999 10:58:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00596 Wed, 15 Dec 1999 12:35:02 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Wed, 15 Dec 1999 09:38:46 -0800 Message-Id: In-Reply-To: <"v04220802b47c5ab23449(a)(091)171.78.30.108(093)*"@MHS> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: kent@bbn.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, You're right. The non-repudiation feature does not seem very useful for IPSEC. One really has to sign a specific document to take advantage of that feature. On the other hand, the repudiability feature of pk encryption does seem useful. To take as an example an issue that has been in the news recently, suppose a gay serviceman (in the US armed forces) is accessing a gay web site (he would be using SSL rather than IPSEC, but I'm just trying to illustrate the repudiability feature). If he uses a digital signature for authentication, the military would be able to prove that he has accessed the site. If he uses pk encryption, the military will not be able to prove it. So the serviceman would find value in using pk encryption rather than digital signature. Since non-repudiation does not seem useful but repudiability does seem useful, this suggests that, as a general design principle, one should use pk encryption for authenticating connections rather than signatures. I'm not proposing to drop signatures from IKE, of course, I'm just theorizing. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE Author: Non-HP-kent (kent@bbn.com) at HP-ColSprings,mimegw5 Date: 12/14/99 12:38 PM Francisco, Whether a signature provides a basis for non-repudiation depends on the details of the generation process. Note that in the case of IPsec, at most one might be able to prove that a peer initiated an SA, but the signature applied during the IKE exchange would not say anything about what data was sent on the SAs later. So, while I like the use of signatures for IKE authentication, I would not argue too strongly for them based on any non-repudiation basis. Steve From owner-ipsec@lists.tislabs.com Wed Dec 15 12:05:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16263; Wed, 15 Dec 1999 12:05:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00897 Wed, 15 Dec 1999 13:40:51 -0500 (EST) Message-ID: <3857E1F9.CCB96076@redcreek.com> Date: Wed, 15 Dec 1999 10:46:17 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: francisco_corella@hp.com CC: pau@watson.ibm.com, ipsec@lists.tislabs.com Subject: Re: A problem with public key encrption in IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francisco, francisco_corella@hp.com wrote: > It seems that IPSEC implementations select the protection requirements > (what they will propose/accept) for phase 1 and phase 2 together, based on > the identity of the peer. I don't know if this is required by one of the > RFCs, or if that's just the way it's done. > > It would make sense, though, to determine the protection requirements for > each phase separately. The protection requirements for phase 1 could be > determined independently of the identity of the peer. (After all, one > purpose of phase 1 is to determine the identity of the peer.) The phase 1 > requirements would not be specified by the SPD, they would be selected by > the IPSEC administrator by means that need not be part of the IPSEC > standard. Then the protection requirements for phase 2 could be determined > based on the identity of the peer established in phase 1. These requirments > would be specified by the SPD. > The requirement for ID PFS may be specific to the peers, i.e. I may require ID PFS for my connections, while other folks I work with do not, meaning they may share phase 1 SAs with one another, while I will not. If you divorce the phase 1 security requirements from the phase 2 security requirements, you remove this capability. Also, as a phase 2 consumer, what assurance would I then have that the protection level of the phase 1 SA is sufficient to protect negotiation of my perhaps highly secured phase 2 SA? Scott From owner-ipsec@lists.tislabs.com Wed Dec 15 12:11:11 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16351; Wed, 15 Dec 1999 12:11:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00935 Wed, 15 Dec 1999 13:43:42 -0500 (EST) Date: Wed, 15 Dec 1999 13:47:22 -0500 (EST) From: "David M. Balenson" Message-Id: <199912151847.NAA06384@clipper.gw.tislabs.com> To: ipsec@tislabs.com Subject: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ipsec@lists.tislabs.com Wed Dec 15 12:25:04 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16693; Wed, 15 Dec 1999 12:25:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01157 Wed, 15 Dec 1999 14:12:36 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust.com> From: Greg Carter To: ipsec@lists.tislabs.com Subject: Latest ipsec-pki-req-04.txt Date: Wed, 15 Dec 1999 14:15:47 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, 3.1 The extendedKeyUsage field Maybe I missed it, but did anybody respond why the extendedKeyUsage MUST contain only the object identifier iKEIntermediate? This now means all ipsec entities require a special ipsec cert. 6.1 Signature-based authentication Main Mode - Certificate Request I would much prefer that we specify only which parts of the exchange where it does not make sense to send these payloads rather than trying to restrict where they are sent. To me it makes perfect sense to send a cert request in 2(responder), 3(initiator), 4(responder) or 5(initiator). Since after the SA is agree you will know if you want a cert. So don't send cert-req in 6. I agree that it only makes sense to send the certs in 5 or 6 to enforce identity protection. 6.3 Content of Certificate payloads "If a responding device is not offering a certificate that will chain to the certificate authority named in the Certificate Request payload, the Certificate payload offered in response to a Certificate Request payload MUST specify a certificate encoding of type NONE." This is completely new behavior. And not very flexible. I'll give an example. IPSec Client is attempting to setup IKE with a Gateway. The client and gateway do not share the same CA, however the CA's are cross certified and a chain from one to the other can be made but requires access to a certificate repository. IPSec client initiates IKE with gateway, certificate repository is behind gateway and client does not have access to it. IPSec client sends cert request, gets back chain, crl, and is happy. Gateway sends cert request, client if conforming to section 6.3 would not respond with its certificate instead with a NONE and negotiation fails. As it would work today, client would send back as much of the chain as it can, which in this case would only be its certificate. Gateway having access to repository builds chain from clients CA to its CA and validates certificate. Negotiation proceeds. A. Obtaining a Certificate for a Device "Regardless of the protocol used, a CA who gets an IKE system's enrollment request that includes the subject and subjectAltName desired for the device MUST include exactly the same subject and subjectAltName in the certificate." As I have said before this will require that a user type in the DN at some console somewhere and get it right. I don't see the need for this restriction. I believe the subject can be modified by the CA in CMP (rfc2510). A.1 Enrollment requests with PKCS10 plus out of band information I am glad this has been spelt out, however it should be mentioned here or in the security considerations section that a hash (fingerprint) of the ASN.1 DER encoded p10 message be done and made available to the operator for verification with the CA. Bye Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html From owner-ipsec@lists.tislabs.com Wed Dec 15 12:54:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17216; Wed, 15 Dec 1999 12:54:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01266 Wed, 15 Dec 1999 14:32:41 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 15 Dec 1999 14:15:19 -0500 To: francisco_corella@hp.com From: Stephen Kent Subject: Re: A problem with public key encrption in IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francisco, Good points. If one wants to support anonymity for encrypted access there are lots of options, but once we add in a requirement for access control, the options narrow. However, the fine line between repudiable and non-repudiable proof of access may be relatively minor in general. A site usually would maintain an audit trail that would record the successful login in any case. To dispute that would entail a lengthy argument about how it might have been altered, etc. I agree that it is preferable to have strong technical controls for NR, and to distinguish between such controls and less stringent methods. However, we must also remember that the banking community has long relied on MACs for authentication/integrity and claimed that an audit trail of MACs provided a basis for NR! Let me suggest a slight variation on this theme. If a user signs some data for authentication, but the data is arbitrary and chosen by the communicating peer, then we can argue that we don't have a good basis for NR, because the user might have been persuaded to sign such data under a variety of circumstances. In that case the peer has the "proof" it needs for authentication, as an input to access control, but the user has not provided technically non-repudiable evidence as part of login. How does the current IKE use of signatures for authentication relate to this model? Steve From owner-ipsec@lists.tislabs.com Wed Dec 15 15:37:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20859; Wed, 15 Dec 1999 15:37:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02037 Wed, 15 Dec 1999 17:01:46 -0500 (EST) Message-ID: <23E9E6DBBF4DD21190BC006008B0213E02CBF542@newman.verisign.com> From: Alex Deacon To: ipsec@lists.tislabs.com Subject: RE: Latest ipsec-pki-req-04.txt Date: Wed, 15 Dec 1999 14:04:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Greg Carter wrote: > > Hi, > > 3.1 The extendedKeyUsage field > > Maybe I missed it, but did anybody respond why the > extendedKeyUsage MUST > contain only the > object identifier iKEIntermediate? > > This now means all ipsec entities require a special ipsec cert. Perhaps I missed this also. Some reasoning as to why ONLY the iKEIntermediate OID can be present in an end entity cert would be great. >[snip] > > > A. Obtaining a Certificate for a Device > "Regardless of the protocol used, a CA who gets an IKE system's > enrollment request that includes the subject and > subjectAltName desired > for the device MUST include exactly the same subject and > subjectAltName > in the certificate." > > As I have said before this will require that a user type in > the DN at some > console somewhere and get it right. I don't see the need for this > restriction. I believe the subject can be modified by the CA in CMP > (rfc2510). I agree completely. > A.1 Enrollment requests with PKCS10 plus out of band information > > I am glad this has been spelt out, however it should be > mentioned here or in > the security considerations section that a hash (fingerprint) > of the ASN.1 > DER encoded p10 message be done and made available to the operator for > verification with the CA. Agree here also. In addition I'd like to clarify the following section of appendix A.1 ".... In addition to CMP and CMC, there are at least two other non-IETF protocols that have been used by a number of IPsec vendors and CAs. The IPsec market has coalesced around one method of enrollment that is not fully defined anywhere other than this document. That method can be called "PKCS10 plus out of band" or "P10POUB", described below. All IKE systems that need to obtain a certificate for the public key MAY do P10POUB, and MAY do CMP and/or CMC in the near future." You will find that CMC has fully defined the P10POUB method described. In fact, one of the main goals of CMC was to standardize and define the use of a simple PKCS#10 and PKCS#7 message for certificate enrollment. It is known as the "simple PKI request/response" method in CMC. Regards, Alex > From owner-ipsec@lists.tislabs.com Wed Dec 15 17:05:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22143; Wed, 15 Dec 1999 17:05:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02449 Wed, 15 Dec 1999 18:45:47 -0500 (EST) Message-Id: <4.2.1.19991215153710.00da0980@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 15 Dec 1999 15:49:48 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Latest ipsec-pki-req-04.txt In-Reply-To: <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:15 PM 12/15/99 -0500, Greg Carter wrote: >3.1 The extendedKeyUsage field > >Maybe I missed it, but did anybody respond why the extendedKeyUsage MUST >contain only the >object identifier iKEIntermediate? > >This now means all ipsec entities require a special ipsec cert. This was discussed at DC with no consensus and small numbers of people arguing vocally in different directions. It would be good to get clarity on this topic soon. Should any old cert be useful for IKE identification? If not, is there something between "any" and "IKE only" that makes sense? >6.1 Signature-based authentication >Main Mode - Certificate Request >I would much prefer that we specify only which parts of the exchange where >it does not make sense to send these payloads rather than trying to restrict >where they are sent. To me it makes perfect sense to send a cert request in >2(responder), 3(initiator), 4(responder) or 5(initiator). Since after the >SA is agree you will know if you want a cert. But doing so in messages 2, 3, and 4 are not described in the message formats in the IKE document. The ISAKMP document says it's OK to put them there (and in step 1, for that matter), but IKE only has slots for them in 5 and 6. What you're proposing is that we change IKE. I think that's fine, but we have to do it somewhere other than the PKI document. >6.3 Content of Certificate payloads >"If a responding device is not offering a certificate that will chain to >the certificate authority named in the Certificate Request payload, the >Certificate payload offered in response to a Certificate Request >payload MUST specify a certificate encoding of type NONE." > >This is completely new behavior. And not very flexible. Disagree. Agree. > I'll give an >example. IPSec Client is attempting to setup IKE with a Gateway. The >client and gateway do not share the same CA, however the CA's are cross >certified and a chain from one to the other can be made but requires access >to a certificate repository. What you're asking for is that both sides, when given a certificate request for a root that they do not know, should guess and send a bunch of certs that weren't requested. There is no way for the responder to the request to know whether the request might have cross-certs with any of its roots, or any of its intermediate certs, for that matter. I propose that this is a bad solution that will cause IKE to fail more often due to much longer responses. Your problem is real, but it is not common (one might say "extremely rare except for Entrust customers"). I think what is proposed here is OK *except* for the case of cross-certification, and that if we want to deal with that problem, we need a solution specific to cross-certs. >A. Obtaining a Certificate for a Device >"Regardless of the protocol used, a CA who gets an IKE system's >enrollment request that includes the subject and subjectAltName desired >for the device MUST include exactly the same subject and subjectAltName >in the certificate." > >As I have said before this will require that a user type in the DN at some >console somewhere and get it right. Maybe not true 100% of the time, but certainly often enough to make fat-fingering errors common. > I don't see the need for this >restriction. I believe the subject can be modified by the CA in CMP >(rfc2510). I'll defer to Rodney to defend this requirement. What do other folks say? >A.1 Enrollment requests with PKCS10 plus out of band information > >I am glad this has been spelt out, however it should be mentioned here or in >the security considerations section that a hash (fingerprint) of the ASN.1 >DER encoded p10 message be done and made available to the operator for >verification with the CA. This seems to me to be an operational issue, not a protocol issue. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Dec 15 22:06:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA20278; Wed, 15 Dec 1999 22:06:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03238 Wed, 15 Dec 1999 23:53:29 -0500 (EST) Message-Id: <4.2.1.19991215204341.00b3cea0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 15 Dec 1999 20:57:54 -0800 To: Tero Kivinen From: Paul Hoffman Subject: Re: Latest ipsec-pki-req-04.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <199912160428.GAA19858@torni.ssh.fi> References: <4.2.1.19991215153710.00da0980@mail.vpnc.org> <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust .com> <4.2.1.19991215153710.00da0980@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote: >The pictures in the IKE documents are ONLY EXAMPLES. They are? I didn't see anywhere in the document that says that or even hints that. Sorry if I'm being dense, but maybe this should be clearer in the new RFC. > > >6.3 Content of Certificate payloads > > >"If a responding device is not offering a certificate that will chain to > > >the certificate authority named in the Certificate Request payload, the > > >Certificate payload offered in response to a Certificate Request > > >payload MUST specify a certificate encoding of type NONE." > > > > > >This is completely new behavior. And not very flexible. > > > > Disagree. Agree. > >I haven't seen that kind of description before. Is somebody really >doing that? I have been told that by at least one shipping vendor; there may be others. >Usually the device has only 1 or 2 certificates for itself. I don't think that's necessarily true. One example is that a remote access user might have many more than that. But even gateways might have ten or more, such as one for each corporate business partner. > If it >doesn't know how to build the chain from its certificates to the CA >the other end provided, why not send those 1 or 2 certificates to the >other end and see if he can make the chain. Because this could turn into an message that is >50K bytes. Very long UDP messages are inherently dangerous, yes? >There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE >notifications that can be used. But you use those when you cannot set up an SA. What if a party sent three cert requests with three different roots, of which you only have one matching. I don't think you should send back two CERTIFICATE-UNAVAILABLE failure notices and a cert; I think you send two NONE cert payloads and a real cert. The other option is to only send certs that do match, and if there are none, you obviously would want to send an error notification. > > Your problem is real, but it is not common (one might say "extremely rare > > except for Entrust customers"). I think what is proposed here is OK > > *except* for the case of cross-certification, and that if we want to deal > > with that problem, we need a solution specific to cross-certs. > >No, I think sending information you have to the other end to see if he >can make sense of it, is the best way to do it. It will allow two >parties to communicate if either one of parties have extra information >that allows him to build the completele path. I still disagree, but am open to this if many folks want to do it. Again, be aware that this means that a request for a root that you don't have might cause the responder to dump a large number of packets on you. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Dec 15 22:57:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21471; Wed, 15 Dec 1999 22:57:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA03282 Thu, 16 Dec 1999 00:36:52 -0500 (EST) Date: Thu, 16 Dec 1999 07:40:42 +0200 (EET) Message-Id: <199912160540.HAA05416@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Hoffman Cc: ipsec@lists.tislabs.com Subject: Re: Latest ipsec-pki-req-04.txt In-Reply-To: <4.2.1.19991215204341.00b3cea0@mail.vpnc.org> References: <4.2.1.19991215153710.00da0980@mail.vpnc.org> <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust .com> <199912160428.GAA19858@torni.ssh.fi> <4.2.1.19991215204341.00b3cea0@mail.vpnc.org> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 23 min X-Total-Time: 40 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman writes: > At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote: > >The pictures in the IKE documents are ONLY EXAMPLES. > They are? I didn't see anywhere in the document that says that or even > hints that. Sorry if I'm being dense, but maybe this should be clearer in > the new RFC. There is some text about that in the 5.5, where it describes the hash calculation: ---------------------------------------------------------------------- ... With the exception of the HASH, SA, and the optional ID payloads, there are no payload ordering restrictions on Quick Mode. HASH(1) and HASH(2) may differ from the illustration above if the order of payloads in the message differs from the illustrative example or if any optional payloads, for example a notify payload, have been chained to the message. ... ---------------------------------------------------------------------- I agree that it should say that more clearly in the beginning of the document. > Because this could turn into an message that is >50K bytes. Very long UDP > messages are inherently dangerous, yes? So the client has 50-80 different end user certificates, but no idea which of those to use for that party? I don't really think clients will have that many certificates. > >There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE > >notifications that can be used. > But you use those when you cannot set up an SA. What if a party sent three > cert requests with three different roots, of which you only have one > matching. I don't think you should send back two CERTIFICATE-UNAVAILABLE > failure notices and a cert; I think you send two NONE cert payloads and a > real cert. What value the NONE certs have? They don't tell the other end anything. Note there is no restriction that you should answer in the same order than the certificate requests came in. Also one certificate request can result in multiple certificate to be sent. > The other option is to only send certs that do match, and if there > are none, you obviously would want to send an error notification. I think most of the implementations out there will reply to those certificate requests they know something about, and silently ignore all of the others. If they don't know how to answer at all there is three choices: 1) Send all end user certificates you have and see if the other end can use them. 2) Send nothing, and hope the other end will dig out your certificates somewhere. 3) Send error notification back and fail. I think the order above is the preferred and also currently most implemented order. I don't think I have ever seen INVALID-CERT-AUTHORITY or CERTIFICATE-UNAVAILABLE notifications. Checking the isakmp-test.ssh.fi site logs, I seem to have received 22 INVALID-CERT-AUTHORITY notifications out of 1337 notifications other implementations have sent to our site, and zero CERTIFICATE-UNAVAILABLE notifications. All of those INVALID-CERT-AUTHORITY notifications came from the single implementation. In total there has been 9652 negotiations from 434 different ip-numbers to the site. The site will always send certificate request payload when using certificates. There is an option to disable sending it though. BTW, I couldn't find a single certificate payloads with none encoding. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Dec 15 23:46:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24046; Wed, 15 Dec 1999 23:46:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03186 Wed, 15 Dec 1999 23:24:44 -0500 (EST) Date: Thu, 16 Dec 1999 06:28:14 +0200 (EET) Message-Id: <199912160428.GAA19858@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Hoffman Cc: ipsec@lists.tislabs.com Subject: Re: Latest ipsec-pki-req-04.txt In-Reply-To: <4.2.1.19991215153710.00da0980@mail.vpnc.org> References: <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust .com> <4.2.1.19991215153710.00da0980@mail.vpnc.org> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 15 min X-Total-Time: 26 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman writes: > Should any old cert be useful for IKE identification? If not, is there > something between "any" and "IKE only" that makes sense? I would say that any certificate is ok, if it doesn't have extended key usage extension. If it has extended key usage extension, then it means that CA wanted to restricts the use of certificate, thus we should respect that, and check that iKEIntermediate is inside that list. So if CA wants to create certificate that can be used for any use, just create it without extended key usage extension. If CA wants to limit the use to only IKE and email, then it will create certificate that contains exteneded key usage extension having emailProtection and iKEIntermediate. > >6.1 Signature-based authentication > >Main Mode - Certificate Request > >I would much prefer that we specify only which parts of the exchange where > >it does not make sense to send these payloads rather than trying to restrict > >where they are sent. To me it makes perfect sense to send a cert request in > >2(responder), 3(initiator), 4(responder) or 5(initiator). Since after the > >SA is agree you will know if you want a cert. > > But doing so in messages 2, 3, and 4 are not described in the message > formats in the IKE document. The ISAKMP document says it's OK to put them The pictures in the IKE documents are ONLY EXAMPLES. They are not supposed to be complete and they are much of other legal ways to put the payloads together (Examples of this is the payload ordering and the optional payloads (certificate, certificate request, notify etc). > there (and in step 1, for that matter), but IKE only has slots for them in > 5 and 6. What you're proposing is that we change IKE. I think that's fine, > but we have to do it somewhere other than the PKI document. IKE does not say that you can only have certificate payloads in messages 5 and 6. In the examples it only shows those payloads in those messages, because they normally appear there, but it does not mean that it is not allowed to send them any other messages. The only restriction IKE makes is that it does NOT allow you to send certificate request payload in a way which would extended the exchange, i.e. in the 6th message of main mode or in the 3rd message of the aggressive mode. > >6.3 Content of Certificate payloads > >"If a responding device is not offering a certificate that will chain to > >the certificate authority named in the Certificate Request payload, the > >Certificate payload offered in response to a Certificate Request > >payload MUST specify a certificate encoding of type NONE." > > > >This is completely new behavior. And not very flexible. > > Disagree. Agree. I haven't seen that kind of description before. Is somebody really doing that? > What you're asking for is that both sides, when given a certificate request > for a root that they do not know, should guess and send a bunch of certs > that weren't requested. There is no way for the responder to the request to > know whether the request might have cross-certs with any of its roots, or > any of its intermediate certs, for that matter. I propose that this is a > bad solution that will cause IKE to fail more often due to much longer > responses. Usually the device has only 1 or 2 certificates for itself. If it doesn't know how to build the chain from its certificates to the CA the other end provided, why not send those 1 or 2 certificates to the other end and see if he can make the chain. There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE notifications that can be used. > Your problem is real, but it is not common (one might say "extremely rare > except for Entrust customers"). I think what is proposed here is OK > *except* for the case of cross-certification, and that if we want to deal > with that problem, we need a solution specific to cross-certs. No, I think sending information you have to the other end to see if he can make sense of it, is the best way to do it. It will allow two parties to communicate if either one of parties have extra information that allows him to build the completele path. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Dec 16 10:09:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15561; Thu, 16 Dec 1999 10:09:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05050 Thu, 16 Dec 1999 11:12:43 -0500 (EST) From: pau@watson.ibm.com Date: Thu, 16 Dec 1999 11:16:40 -0500 Message-Id: <9912161616.AA21828@secpwr.watson.ibm.com> To: hugo@ee.technion.ac.il Subject: Re: A problem with public key encrption in IKE Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: gO49VuL9N6uN974E+ZK+mw== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, my memory did not serve me well. My apology to Dan, Hugo and Ran. Pau-Chen > From owner-ipsec@lists.tislabs.com Wed Dec 15 05:21:35 1999 > Date: Wed, 15 Dec 1999 11:53:38 +0200 (IST) > From: Hugo Krawczyk > To: pau@watson.ibm.com > Cc: ipsec list > Subject: Re: A problem with public key encrption in IKE > In-Reply-To: <9912141911.AA24012@secpwr.watson.ibm.com> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-ipsec@lists.tislabs.com > Precedence: bulk > Content-Length: 521 > Status: RO > > Pau, > > > Having two forms of public key encryption modes came from some > > miscommunication we (I, Hugo and Ran) had with Dan. > > these two modes are NOT the result of miscommunication with Dan. > The original mode was taken by Dan from the Oakley draft > which was Hilarie's implementation of the PK encryption > mode of SKEME. > > The revised mode is more in line with what I had in mind when > designing SKEME. Especially, the fact that it uses a single costly > encryption-decryption operation at each party rather than two. > > Hugo > From owner-ipsec@lists.tislabs.com Thu Dec 16 13:17:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18444; Thu, 16 Dec 1999 13:17:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05748 Thu, 16 Dec 1999 14:52:34 -0500 (EST) Message-ID: <385943E4.6B012D63@fokus.gmd.de> Date: Thu, 16 Dec 1999 20:56:20 +0100 From: Cristian Constantin X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Dest addr. in tunnel mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When referring to "IPv4 -- Header Construction for Tunnel Mode" RFC 2401 says: ---------------------------- 3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet. ----------------------------- Nowhere else is said that the SA MUST contain the dest address... Or maybe I didn't see it?... Thanx for your prompt answer Cristian From owner-ipsec@lists.tislabs.com Thu Dec 16 13:29:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA18687; Thu, 16 Dec 1999 13:29:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05804 Thu, 16 Dec 1999 15:06:06 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B10197DACB@sothmxs06.entrust.com> From: Greg Carter To: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: RE: Latest ipsec-pki-req-04.txt Date: Thu, 16 Dec 1999 15:09:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Instead of a lot of quoted text I'll restate a few things. First I agree with all of Tero's comments. Next to your comments Paul: - Certificate Request Payload As Tero stated the IKE diagrams are guides. ISAKMP states that payloads can come in any order in the packet, optional payloads any time (rfc 2408 4.1 ISAKMP Exchange Types). I think the only restriction to this is that the SA payload must be first. The above is my "But it says this here" argument. Now my "but we have been doing it this way" argument. As an implementer I have taken advantage of this to get the cert requests out of the way as soon as I know that I am doing a signature mode authentication. I have been doing this for over 2 years at many bakeoffs without harm to anyone. I'll also note that IKE doesn't even show cert request payloads in the packet diagrams, so to say that sending them before 4 or 5 is 'changing IKE' isn't really true. Perhaps you were confused with Certificate payloads? - 6.3 Content of Certificate payloads You state that you disagree that this is new behavior. I haven't found where it states in IKE or ISAKMP that you are to respond with a cert type of NONE when you can not build a chain to the requested CA? ISAKMP states that a notify with value CERTIFICATE-UNAVAILABLE MAY be sent. However I would like to think that an optimistic approach of continuing the negotiation is practical. Please re-read my example. I am not at all proposing that an entity respond with a list of certs that MAY chain to some root. I said 1 cert, that being the entities cert. The other end having access to the certificate repository can build a correct chain and provide it to the peer. And having access to the repository can determine trust in the peers certificate. I could give other examples for hierarchy but I will leave that as an exercise to the reader :) I used cross certification because it was a clear example of the problem that is solved leaving IKE as it is. I really don't see the logic in defining new behavior that limit's the usefulness of IKE. A.1 Enrollment requests with PKCS10 plus out of band information - Re hash of DER encoded request for verification You state - "This seems to me to be an operational issue, not a protocol issue." A PKCS10 blob needs to be authenticated, simply verifying the signature on it does nothing to verify the authenticity of the request. It means that whomever created the request has access to the private key. Since this document is defining the format and suggests methods of transporting the request, I think it is wise that it also state a baseline cryptographic means of authenticating the requests. I have seen some products that provide no way of authenticating the P10 messages they generate, so it would be nice to include this here. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Wednesday, December 15, 1999 6:50 PM To: ipsec@lists.tislabs.com Subject: Re: Latest ipsec-pki-req-04.txt At 02:15 PM 12/15/99 -0500, Greg Carter wrote: >6.1 Signature-based authentication >Main Mode - Certificate Request But doing so in messages 2, 3, and 4 are not described in the message formats in the IKE document. The ISAKMP document says it's OK to put them there (and in step 1, for that matter), but IKE only has slots for them in 5 and 6. What you're proposing is that we change IKE. I think that's fine, but we have to do it somewhere other than the PKI document. From owner-ipsec@lists.tislabs.com Fri Dec 17 11:35:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12238; Fri, 17 Dec 1999 11:35:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00385 Fri, 17 Dec 1999 12:59:26 -0500 (EST) Message-Id: <3.0.6.32.19991217074511.03a15790@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 17 Dec 1999 07:45:11 -0800 To: Tero Kivinen , Paul Hoffman From: Rodney Thayer Subject: Re: Latest ipsec-pki-req-04.txt - where do certs go in IKE Cc: ipsec@lists.tislabs.com In-Reply-To: <199912160428.GAA19858@torni.ssh.fi> References: <4.2.1.19991215153710.00da0980@mail.vpnc.org> <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust .com> <4.2.1.19991215153710.00da0980@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote: >Paul Hoffman writes: >> >6.1 Signature-based authentication >> >Main Mode - Certificate Request >> >I would much prefer that we specify only which parts of the exchange where >> >it does not make sense to send these payloads rather than trying to restrict >> >where they are sent. To me it makes perfect sense to send a cert request in >> >2(responder), 3(initiator), 4(responder) or 5(initiator). Since after the >> >SA is agree you will know if you want a cert. >> >> But doing so in messages 2, 3, and 4 are not described in the message >> formats in the IKE document. The ISAKMP document says it's OK to put them > >The pictures in the IKE documents are ONLY EXAMPLES. They are not >supposed to be complete and they are much of other legal ways to put >the payloads together (Examples of this is the payload ordering and >the optional payloads (certificate, certificate request, notify etc). > >> there (and in step 1, for that matter), but IKE only has slots for them in >> 5 and 6. What you're proposing is that we change IKE. I think that's fine, >> but we have to do it somewhere other than the PKI document. > >IKE does not say that you can only have certificate payloads in >messages 5 and 6. In the examples it only shows those payloads in >those messages, because they normally appear there, but it does not >mean that it is not allowed to send them any other messages. > >The only restriction IKE makes is that it does NOT allow you to send >certificate request payload in a way which would extended the >exchange, i.e. in the 6th message of main mode or in the 3rd message >of the aggressive mode. The verbal rule for cert requests and certs in IKE was "anything can arrive from deep space at any random time and you have to just cope". This was, of course, stunningly bad protocol design. If we want to quantify this, let's update (some appropriate) document, let's not tell people to read obscure footnotes in random irrelevant sections. If we want this thing to be a usable protocol, let's document when and where you are supposed to send what. From owner-ipsec@lists.tislabs.com Fri Dec 17 11:35:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12255; Fri, 17 Dec 1999 11:35:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00339 Fri, 17 Dec 1999 12:56:25 -0500 (EST) Message-Id: <3.0.6.32.19991217072814.038b8a90@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 17 Dec 1999 07:28:14 -0800 To: Tero Kivinen , Paul Hoffman From: Rodney Thayer Subject: Re: Latest ipsec-pki-req-04.txt illustrations considered harmful Cc: ipsec@lists.tislabs.com In-Reply-To: <199912160540.HAA05416@torni.ssh.fi> References: <4.2.1.19991215204341.00b3cea0@mail.vpnc.org> <4.2.1.19991215153710.00da0980@mail.vpnc.org> <01E1D01C12D7D211AFC70090273D20B10197DA9F@sothmxs06.entrust .com> <199912160428.GAA19858@torni.ssh.fi> <4.2.1.19991215204341.00b3cea0@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk this is obscene, no new developer would have caught this. At 07:40 AM 12/16/99 +0200, Tero Kivinen wrote: >Paul Hoffman writes: >> At 06:28 AM 12/16/99 +0200, Tero Kivinen wrote: >> >The pictures in the IKE documents are ONLY EXAMPLES. >> They are? I didn't see anywhere in the document that says that or even >> hints that. Sorry if I'm being dense, but maybe this should be clearer in >> the new RFC. > >There is some text about that in the 5.5, where it describes the hash >calculation: >---------------------------------------------------------------------- >... > With the exception of the HASH, SA, and the optional ID payloads, > there are no payload ordering restrictions on Quick Mode. HASH(1) and > HASH(2) may differ from the illustration above if the order of > payloads in the message differs from the illustrative example or if > any optional payloads, for example a notify payload, have been > chained to the message. >... >---------------------------------------------------------------------- > >I agree that it should say that more clearly in the beginning of the >document. > > >> Because this could turn into an message that is >50K bytes. Very long UDP >> messages are inherently dangerous, yes? > >So the client has 50-80 different end user certificates, but no idea >which of those to use for that party? I don't really think clients >will have that many certificates. > >> >There is also INVALID-CERT-AUTHORITY and CERTIFICATE-UNAVAILABLE >> >notifications that can be used. >> But you use those when you cannot set up an SA. What if a party sent three >> cert requests with three different roots, of which you only have one >> matching. I don't think you should send back two CERTIFICATE-UNAVAILABLE >> failure notices and a cert; I think you send two NONE cert payloads and a >> real cert. > >What value the NONE certs have? They don't tell the other end >anything. Note there is no restriction that you should answer in the >same order than the certificate requests came in. Also one certificate >request can result in multiple certificate to be sent. > >> The other option is to only send certs that do match, and if there >> are none, you obviously would want to send an error notification. > >I think most of the implementations out there will reply to those >certificate requests they know something about, and silently ignore >all of the others. If they don't know how to answer at all there is >three choices: > > 1) Send all end user certificates you have and see if the > other end can use them. > 2) Send nothing, and hope the other end will dig out your > certificates somewhere. > 3) Send error notification back and fail. > >I think the order above is the preferred and also currently most >implemented order. I don't think I have ever seen >INVALID-CERT-AUTHORITY or CERTIFICATE-UNAVAILABLE notifications. > >Checking the isakmp-test.ssh.fi site logs, I seem to have received 22 >INVALID-CERT-AUTHORITY notifications out of 1337 notifications other >implementations have sent to our site, and zero >CERTIFICATE-UNAVAILABLE notifications. All of those >INVALID-CERT-AUTHORITY notifications came from the single >implementation. In total there has been 9652 negotiations from 434 >different ip-numbers to the site. > >The site will always send certificate request payload when using >certificates. There is an option to disable sending it though. > >BTW, I couldn't find a single certificate payloads with none encoding. >-- >kivinen@iki.fi Work : +358-9-4354 3218 >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Fri Dec 17 11:35:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12237; Fri, 17 Dec 1999 11:35:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00374 Fri, 17 Dec 1999 12:58:25 -0500 (EST) Message-Id: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 17 Dec 1999 07:35:00 -0800 To: Alex Deacon , ipsec@lists.tislabs.com From: Rodney Thayer Subject: RE: Latest ipsec-pki-req-04.txt - EKU In-Reply-To: <23E9E6DBBF4DD21190BC006008B0213E02CBF542@newman.verisign.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess we've been staring at this too long. Let's try this again. I wanted ONE eku in a cert. I think it is INSECURE to have "swiss army knife" certificates that do multiple functions. This comment applies to SMIME, IPsec, TLS -- any cert usage. Others wanted multiple functions. I believe (some PKIX lawyer check me on this...) that 2459 allows any number of EKU's (wanna parse a cert with 572 EKU's, anyone? Can you say "architecturally irresponsible"?) I believe we got the text wrong, as I believe the rough consensus on this is that it should say... In a certificate for an IPsec end entity, the extendedKeyUsage field (commonly called "EKU") SHOULD be present. In order to indicate this certificate is allowed to be used for IPsec, it MUST contain the object identifier iKEIntermediate (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or 1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD NOT accept end-entity certificates that do not follow this rule. Now, I realize we're going around in circles on this, so I expect others to shout this down and that first 'MUST' (see my * above) will be watered down to a SHOULD. By the way, one thing we meant to do here was to stop talking about IPsec intermediate vs. end systems, which is a concept we did not have consensus on. Again I think this is a security issue. I don't want some random can wrapping my packets in IPsec and claiming it was a legitimate gateway if it was a mere end system. At 02:04 PM 12/15/99 -0800, Alex Deacon wrote: >Hello, > > >Greg Carter wrote: >> >> Hi, >> >> 3.1 The extendedKeyUsage field >> >> Maybe I missed it, but did anybody respond why the >> extendedKeyUsage MUST >> contain only the >> object identifier iKEIntermediate? >> >> This now means all ipsec entities require a special ipsec cert. > >Perhaps I missed this also. Some reasoning as to why ONLY the >iKEIntermediate OID can be present in an end entity cert would be great. > >>[snip] >> >> >> A. Obtaining a Certificate for a Device >> "Regardless of the protocol used, a CA who gets an IKE system's >> enrollment request that includes the subject and >> subjectAltName desired >> for the device MUST include exactly the same subject and >> subjectAltName >> in the certificate." >> >> As I have said before this will require that a user type in >> the DN at some >> console somewhere and get it right. I don't see the need for this >> restriction. I believe the subject can be modified by the CA in CMP >> (rfc2510). > >I agree completely. > >> A.1 Enrollment requests with PKCS10 plus out of band information >> >> I am glad this has been spelt out, however it should be >> mentioned here or in >> the security considerations section that a hash (fingerprint) >> of the ASN.1 >> DER encoded p10 message be done and made available to the operator for >> verification with the CA. > >Agree here also. > >In addition I'd like to clarify the following section of appendix A.1 > >".... In addition to CMP and CMC, there are >at least two other non-IETF protocols that have been used by a number >of IPsec vendors and CAs. > >The IPsec market has coalesced around one method of enrollment that is >not fully defined anywhere other than this document. That method can be >called "PKCS10 plus out of band" or "P10POUB", described below. All >IKE systems that need to obtain a certificate for the public key MAY >do P10POUB, and MAY do CMP and/or CMC in the near future." > >You will find that CMC has fully defined the P10POUB method described. In >fact, one of the main goals of CMC was to standardize and define the use of >a simple PKCS#10 and PKCS#7 message for certificate enrollment. It is known >as the "simple PKI request/response" method in CMC. > >Regards, >Alex > > > > >> > From owner-ipsec@lists.tislabs.com Fri Dec 17 13:39:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13840; Fri, 17 Dec 1999 13:39:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00834 Fri, 17 Dec 1999 13:57:52 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Fri, 17 Dec 1999 11:01:08 -0800 Message-Id: In-Reply-To: <"v04220805b47d9715f5db(a)(091)171.78.30.108(093)*"@MHS> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: kent@bbn.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, If one is allowed to argue that one has been persuaded to sign random data, then the whole concept of a digital signature collapses. Remember that when a document is signed, the digital signature is applied to a cryptographic hash of the document and the hash is indistinguishable from random data if you don't know how it was generated. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE Author: Non-HP-kent (kent@bbn.com) at HP-ColSprings,mimegw5 Date: 12/15/99 11:15 AM Francisco, Good points. If one wants to support anonymity for encrypted access there are lots of options, but once we add in a requirement for access control, the options narrow. However, the fine line between repudiable and non-repudiable proof of access may be relatively minor in general. A site usually would maintain an audit trail that would record the successful login in any case. To dispute that would entail a lengthy argument about how it might have been altered, etc. I agree that it is preferable to have strong technical controls for NR, and to distinguish between such controls and less stringent methods. However, we must also remember that the banking community has long relied on MACs for authentication/integrity and claimed that an audit trail of MACs provided a basis for NR! Let me suggest a slight variation on this theme. If a user signs some data for authentication, but the data is arbitrary and chosen by the communicating peer, then we can argue that we don't have a good basis for NR, because the user might have been persuaded to sign such data under a variety of circumstances. In that case the peer has the "proof" it needs for authentication, as an input to access control, but the user has not provided technically non-repudiable evidence as part of login. How does the current IKE use of signatures for authentication relate to this model? Steve From owner-ipsec@lists.tislabs.com Fri Dec 17 14:29:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14760; Fri, 17 Dec 1999 14:29:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01268 Fri, 17 Dec 1999 15:49:20 -0500 (EST) Message-ID: <385AA261.6616EBC6@nt.com> Date: Fri, 17 Dec 1999 15:51:45 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Rodney Thayer , ipsec@lists.tislabs.com Subject: Re: Latest ipsec-pki-req-04.txt - EKU References: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rodney Thayer wrote: > > I guess we've been staring at this too long. Let's try this > again. > > I wanted ONE eku in a cert. I think it is INSECURE to have > "swiss army knife" certificates that do multiple functions. > This comment applies to SMIME, IPsec, TLS -- any cert usage. > I think that in some environments, having "swiss army knife" certs could potentially be insecure. I don't agree that we should construct a requirements statement that says that Swiss Army Knife certificates are disallowed. There are some environments where issuing a certificate-per-application is operationally inconvenient, and bordering on impossible. Consider a corporate environment, where "them that is in charge" issue certs for use by all applications. What is the semantic difference between a bunch of certificates issued by "them", each one asserting: "This is Marcus Leech [for S/MIME purposes]" -- Signed "them" "This is Marcus Leech [for IPSEC purposes]" -- Signed "them" "This is Marcus Leech [for TLS purposes]" -- Signed "them" vs "This is Marcus Leech [for S/MIME, IPSEC, TLS, FOO purposes" -- Signed "them" For one thing, existing crypto token technology has limited storage capability, and if one assumes different private keys for each of the application-specific certs, you quickly run out of storage on your tokens. Storage capacity in token technology isn't exactly racing along like a rabit, and no amount of us wishing it were so [or engineering protocols to make it necessary] is going to change that. > > I believe (some PKIX lawyer check me on this...) that 2459 allows > any number of EKU's (wanna parse a cert with 572 EKU's, anyone? > Can you say "architecturally irresponsible"?) > That's certainly the way I read RFC2459. While I certainly am personally repulsed at the though of needing 572 EKU's in a certificate, I can't see why parsing 572 is any more difficult than parsing 1, once you have the machinery in the code. Will it take longer? Yes, but certainly nowhere near what it takes to do cert chain validation... > I believe we got the text wrong, as I believe the rough consensus on > this is that it should say... > > In a certificate for an IPsec end entity, the extendedKeyUsage field > (commonly called "EKU") SHOULD be present. In order to indicate this > certificate is allowed to be used for IPsec, it MUST contain the > object identifier iKEIntermediate > (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or > 1.3.6.1.5.5.8.2.2). An IKE system that conforms to this profile SHOULD > NOT accept end-entity certificates that do not follow this rule. > > Now, I realize we're going around in circles on this, so I expect others > to shout this down and that first 'MUST' (see my * above) will be watered > down to a SHOULD. > I disagree that we need to even say "SHOULD"--such decision is an operational one based on the environment. The protocol should be agnostic on this. Operationally, I'm using certificates that don't have ANY EKU at all. I sure as heck don't want to have an interoperability failure because the certs I've been issuing for other purposes for several years are suddenly worthless to me for IPSEC because of the WG decided that an IKE EKU was necessary, and my IPSEC vendor went along with it. Should I be able to configure my IPSEC implementation to insist on certain things being present in the certificate? Absolutely! Should the WG mandate certain things? Only when functionality and interoperability cannot be delivered in any other way. Similarly, I should be able to configure my CA/certificate-issuing-machinery to set things in the cert that allow me to do good things. These should be based on my own operational policy, and not a policy that the WG thinks is "cool". -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Fri Dec 17 15:20:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15402; Fri, 17 Dec 1999 15:20:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04578 Fri, 17 Dec 1999 17:02:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 17 Dec 1999 15:16:59 -0500 To: francisco_corella@hp.com From: Stephen Kent Subject: Re: A problem with public key encrption in IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francisco, > Steve, > > If one is allowed to argue that one has been persuaded to sign >random data, then the whole concept of a digital signature >collapses. Remember that when a document is signed, the digital >signature is applied to a cryptographic hash of the document and >the hash is indistinguishable from random data if you don't know >how it was generated. Well, not all signatures are intended to be non-repudiable! Sometimes we sign things purely for authentication. As we have discussed extensively on the PKIX list, one should exercise care in setting the key usage bits, to distinguish the intent of signing as repudiable or non-repudiable. So, IF one wished to use signature-based authentication with IKE, and wished to avoid any connotation of non-repudiation, it is feasible to do that. Steve From owner-ipsec@lists.tislabs.com Fri Dec 17 15:45:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15699; Fri, 17 Dec 1999 15:45:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05051 Fri, 17 Dec 1999 17:30:14 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Fri, 17 Dec 1999 14:34:00 -0800 Message-Id: In-Reply-To: <"v04220803b480480a6852(a)(091)171.78.30.108(093)*"@MHS> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: kent@bbn.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Thanks. I hadn't thought of the possibility of using key usage bits for that purpose. (I'm not on the PKIX list.) Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE Author: Non-HP-kent (kent@bbn.com) at HP-ColSprings,mimegw5 Date: 12/17/99 12:16 PM Francisco, > Steve, > > If one is allowed to argue that one has been persuaded to sign >random data, then the whole concept of a digital signature >collapses. Remember that when a document is signed, the digital >signature is applied to a cryptographic hash of the document and >the hash is indistinguishable from random data if you don't know >how it was generated. Well, not all signatures are intended to be non-repudiable! Sometimes we sign things purely for authentication. As we have discussed extensively on the PKIX list, one should exercise care in setting the key usage bits, to distinguish the intent of signing as repudiable or non-repudiable. So, IF one wished to use signature-based authentication with IKE, and wished to avoid any connotation of non-repudiation, it is feasible to do that. Steve From owner-ipsec@lists.tislabs.com Fri Dec 17 17:20:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA16748; Fri, 17 Dec 1999 17:20:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05309 Fri, 17 Dec 1999 19:12:12 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Fri, 17 Dec 1999 16:15:51 -0800 Message-Id: In-Reply-To: <3857E1F9.CCB96076@redcreek.com> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: skelly@redcreek.com Cc: francisco_corella@hp.com, pau@watson.ibm.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, << The requirement for ID PFS may be specific to the peers, i.e. I may require ID PFS for my connections, while other folks I work with do not, meaning they may share phase 1 SAs with one another, while I will not. If you divorce the phase 1 security requirements from the phase 2 security requirements, you remove this capability. >> I'm not sure I understand this point. I think you are saying that you want to specify ID PFS for some cnnections but not others. That's fine, but I don't see the difficulty. ID PFS can be specified as a phase 2 requirement. Suppose IKE receives a request to establish a phase 2 SA. The request specfies an IP address. There may or may not be already a phase 1 SA for that IP address. If there is one, IKE can find out the identity associated with it, and use that identity, together with the port and protocol info in the request, to look up the SPD and decide whether to provide ID PFS or not. (If ID PFS is not needed IKE may reuse the phase 1 SA; if it is needed, IKE must use a new phase 1 SA, and get rid of it after establishing the phase 2 SA.) If there is no existing phase 1 SA for that IP address, IKE sets one up and finds out the identity of the peer. Then it looks up the SPD and decides whether ID PFS is needed or not. (If needed IKE will delete the phase 1 SA after using it, otherwise it will keep it.) << Also, as a phase 2 consumer, what assurance would I then have that the protection level of the phase 1 SA is sufficient to protect negotiation of my perhaps highly secured phase 2 SA? >> Every phase 1 SA should provide sufficient protection to protect negociation of any phase 2 SA that may have to be established. I understand the need to provide different levels of protection for phase 2 SAs, e.g. encryption is expensive and may be needed on an Internet connection but not on an intranet connection. But I don't see much motivation for skimping on the protection level for a phase 1 SA. For example, using DES instead of 3DES won't give you much of a performance improvement. Francisco From owner-ipsec@lists.tislabs.com Sat Dec 18 08:24:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28120; Sat, 18 Dec 1999 08:24:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07051 Sat, 18 Dec 1999 09:39:58 -0500 (EST) Message-ID: <385B9D44.C57AE522@ix.netcom.com> Date: Sat, 18 Dec 1999 06:42:12 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: francisco_corella@hp.com CC: skelly@redcreek.com, pau@watson.ibm.com, ipsec@lists.tislabs.com Subject: Re: A problem with public key encrption in IKE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francisco, francisco_corella@hp.com wrote: > << > The requirement for ID PFS may be specific to the peers, i.e. I > may require ID PFS for my connections, while other folks I work > with do not, meaning they may share phase 1 SAs with one > another, while I will not. If you divorce the phase 1 security > requirements from the phase 2 security requirements, you remove > this capability. > >> > > I'm not sure I understand this point. I think you are saying that you > want to specify ID PFS for some cnnections but not others. That's fine, > but I don't see the difficulty. ID PFS can be specified as a phase 2 > requirement. Of course, you are right, and this is how the ID PFS requirement should be specified. Another issue which occurs to me is that phase 2 IDs with respect to authentication are currently tied to the phase 1 SA. If a security gateway (sgw) is to provide individualized authentication for hosts which it protects, it must use unique IDs for phase 1. These IDs must be tied to the phase 2 SAs which they authenticate, and I think this means that phase 1 configuration is tied to phase 2 configuration. Do you have a model which simplifies this? > << > Also, as a phase 2 consumer, what assurance would I then have > that the protection level of the phase 1 SA is sufficient to > protect negotiation of my perhaps highly secured phase 2 SA? > >> > > Every phase 1 SA should provide sufficient protection to protect > negociation of any phase 2 SA that may have to be established. > > I understand the need to provide different levels of protection for phase 2 > SAs, e.g. encryption is expensive and may be needed on an Internet > connection but not on an intranet connection. But I don't see much > motivation for skimping on the protection level for a phase 1 SA. For > example, using DES instead of 3DES won't give you much of a performance > improvement. One other option that may be provided at the phase 2 (negotiation) level is key PFS. While I agree to some extent with your assertion, I think that you imply that every phase 1 SA should provide for key PFS automatically. Is this right? Scott From owner-ipsec@lists.tislabs.com Mon Dec 20 08:01:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22657; Mon, 20 Dec 1999 08:01:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11414 Mon, 20 Dec 1999 08:52:34 -0500 (EST) Date: Mon, 20 Dec 1999 15:55:13 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Subject: signture mode and non-repudiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > Well, not all signatures are intended to be non-repudiable! > Sometimes we sign things purely for authentication. As we have > discussed extensively on the PKIX list, one should exercise care in > setting the key usage bits, to distinguish the intent of signing as > repudiable or non-repudiable. So, IF one wished to use > signature-based authentication with IKE, and wished to avoid any > connotation of non-repudiation, it is feasible to do that. Even if a user U insists that his use of the signature mode does not provide non-repudiation (by usage bits or whatever means) still a person holding U's signature on the establishment of an ipsec SA can prove to a third party that U established that SA. This is not a issue of legal binding provided by the signature (and accepted by the signer) but a privacy or confidentiality issue of leaving your "fingerprints" in the places you visited in Internet. In general, I recommend to talk here about "deniability" (or undeniability) rather than non-repudiation (which has stronger legal connotations). In this context it is important to remark that providing non-repudiation of SA establishment is NOT a requirement of ipsec. To the contrary, it is to some extent a drawback of the signature mode (encryption mode deals better with this issue). Moreover, the signature mode of IKE has been designed to minimize the ``non-repudiation effect''. How? By letting the user of this mode (the signer) to find collisions in the input to the signature function. This is possible under certain instantiations of the prf function. To see this note that the values HASH (_I and _R) over which the signature is computed are the result of applying a prf to some data. A good choice of a prf could be, for example, 3DES in CBC-MAC mode. This would serve very well the purpose of the signature mode (i.e., as a strong authentication of the key-exchange) but will also allow the signer to claim that she signed a different message than the one she really did. (This is a good crypto class exercise: the user that knows the 3DES key used to produce HASH can easily find a different message that maps to the same output of the prf!) A collision like this may not be sufficient for the user to convince a journalist that he did not talk to some dubious party over the Internet, but will be enough to invalidate a legally acceptable non-repudiation property. On the other hand, if anyone insists in using the signature mode for non-repudiation purposes (I do not recommend that) then he can use a prf which is also collision resistant (e.g. HMAC-SHA1). Hugo From owner-ipsec@lists.tislabs.com Mon Dec 20 12:04:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25960; Mon, 20 Dec 1999 12:04:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12761 Mon, 20 Dec 1999 13:22:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <385AA261.6616EBC6@nt.com> References: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> <385AA261.6616EBC6@nt.com> Date: Mon, 20 Dec 1999 13:21:37 -0500 To: "Marcus Leech" From: Stephen Kent Subject: Re: Latest ipsec-pki-req-04.txt - EKU Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Marcus, I agree with most of comments and would like to add a clarification. While it may not be appropriate to require the presence of an EKU in an IPsec implementation, it may be appropriate to require the ability to configure such constraints in every IPsec implementation, to ensure that folks have this local configuration option. Steve From owner-ipsec@lists.tislabs.com Mon Dec 20 12:59:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26605; Mon, 20 Dec 1999 12:59:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13286 Mon, 20 Dec 1999 14:32:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> References: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> Date: Mon, 20 Dec 1999 14:33:11 -0500 To: Rodney Thayer From: Stephen Kent Subject: RE: Latest ipsec-pki-req-04.txt - EKU Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rodney, > >I believe (some PKIX lawyer check me on this...) that 2459 allows >any number of EKU's (wanna parse a cert with 572 EKU's, anyone? >Can you say "architecturally irresponsible"?) Yes, you can insert multiple EKU. No, there is no limit, just as there is no limit on the number of attributes in a DN, or the number of extensions in a cert. If we tried to nail down the numbers for each of these parameters, we would still be arguing over them today :-). Steve From owner-ipsec@lists.tislabs.com Mon Dec 20 13:39:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27013; Mon, 20 Dec 1999 13:39:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13427 Mon, 20 Dec 1999 15:11:48 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 20 Dec 1999 15:11:31 -0500 To: Hugo Krawczyk From: Stephen Kent Subject: Re: signture mode and non-repudiation Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, >Stephen Kent wrote: > > > Well, not all signatures are intended to be non-repudiable! > > Sometimes we sign things purely for authentication. As we have > > discussed extensively on the PKIX list, one should exercise care in > > setting the key usage bits, to distinguish the intent of signing as > > repudiable or non-repudiable. So, IF one wished to use > > signature-based authentication with IKE, and wished to avoid any > > connotation of non-repudiation, it is feasible to do that. > >Even if a user U insists that his use of the signature mode does not >provide non-repudiation (by usage bits or whatever means) still a person >holding U's signature on the establishment of an ipsec SA can prove to >a third party that U established that SA. This is not a issue of legal >binding provided by the signature (and accepted by the signer) but a >privacy or confidentiality issue of leaving your "fingerprints" in the >places you visited in Internet. >In general, I recommend to talk here about "deniability" (or >undeniability) rather than non-repudiation (which has stronger legal >connotations). > >In this context it is important to remark that providing non-repudiation >of SA establishment is NOT a requirement of ipsec. To the contrary, >it is to some extent a drawback of the signature mode (encryption mode >deals better with this issue). I agree that we should separate legal from technical issues here. However, my point was precisely that if we adopt technical measures suitable for authentication, but NOT suitable for non-repudiation, then we can avoid this perceived problem. >Moreover, the signature mode of IKE has been designed to minimize the >``non-repudiation effect''. >How? By letting the user of this mode (the signer) to find collisions in >the input to the signature function. This is possible under certain >instantiations of the prf function. >To see this note that the values HASH (_I and _R) over which the signature >is computed are the result of applying a prf to some data. >A good choice of a prf could be, for example, 3DES in CBC-MAC mode. >This would serve very well the purpose of the signature mode >(i.e., as a strong authentication of the key-exchange) but will also >allow the signer to claim that she signed a different message than the >one she really did. (This is a good crypto class exercise: the user that >knows the 3DES key used to produce HASH can easily find a different message >that maps to the same output of the prf!) Yes, as first shown in a paper by Gligor and a grad student a number of years ago, when they noted that DES-MAC made a poor hash function in an early version of PEM. > >A collision like this may not be sufficient for the user to convince a >journalist that he did not talk to some dubious party over the Internet, >but will be enough to invalidate a legally acceptable >non-repudiation property. > >On the other hand, if anyone insists in using the signature mode for >non-repudiation purposes (I do not recommend that) then he can use >a prf which is also collision resistant (e.g. HMAC-SHA1). I would go beyond this to suggest that we standardize on a function for the signed data that is intentionally not collision resistant, without worrying about the implications for the PRF re key selection in general. That way we could avoid unintentional NR "features" of signature-based IKE authentication. Steve From owner-ipsec@lists.tislabs.com Mon Dec 20 14:13:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27451; Mon, 20 Dec 1999 14:13:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13537 Mon, 20 Dec 1999 15:48:59 -0500 (EST) Message-ID: <385E967D.A74087D5@nt.com> Date: Mon, 20 Dec 1999 15:50:05 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: Latest ipsec-pki-req-04.txt - EKU References: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> <385AA261.6616EBC6@nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Marcus, > > I agree with most of comments and would like to add a clarification. > While it may not be appropriate to require the presence of an EKU in > an IPsec implementation, it may be appropriate to require the ability > to configure such constraints in every IPsec implementation, to > ensure that folks have this local configuration option. > > Steve Oh, absolutely. I just don't think that it's within the mandate of the WG to require a certain local policy, which is what this amounts to. Parts of this discussion would be appropriate to the IPSP WG. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@lists.tislabs.com Mon Dec 20 19:58:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA18115; Mon, 20 Dec 1999 19:58:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA14696 Mon, 20 Dec 1999 21:37:25 -0500 (EST) Message-ID: <385EE946.F19D6AAB@263.net> Date: Tue, 21 Dec 1999 10:43:18 +0800 From: ouyangyi X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: tell me something about the frees/wan References: <3.0.6.32.19991217073500.03a12d50@216.240.42.209> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have got the frees/wan software,but I don't know whether the frees/wan supprot the host-to-host or host-to-security gateway,please tell me .Thank you. From owner-ipsec@lists.tislabs.com Tue Dec 21 06:10:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14028; Tue, 21 Dec 1999 06:10:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15871 Tue, 21 Dec 1999 07:33:03 -0500 (EST) Date: Tue, 21 Dec 1999 14:34:45 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: signture mode and non-repudiation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > >On the other hand, if anyone insists in using the signature mode for > >non-repudiation purposes (I do not recommend that) then he can use > >a prf which is also collision resistant (e.g. HMAC-SHA1). > > I would go beyond this to suggest that we standardize on a function > for the signed data that is intentionally not collision resistant, > without worrying about the implications for the PRF re key selection > in general. That way we could avoid unintentional NR "features" of > signature-based IKE authentication. > > Steve I do not think that this needs standardization (after all, people seem to be in total love with hash functions as prf's and these functions do have the non-collisions property). Maybe a note in the IKE document explaining this issue can be of help. Hugo From owner-ipsec@lists.tislabs.com Tue Dec 21 07:05:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15051; Tue, 21 Dec 1999 07:05:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16108 Tue, 21 Dec 1999 08:43:59 -0500 (EST) Message-ID: <385F63C4.4B1F53ED@F-Secure.com> Date: Tue, 21 Dec 1999 13:25:56 +0200 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: MM with signatures and dynamic IP addresses? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is the responder supposed to do in the following scenario: Main mode with signature authentication is being used and the initiator chooses the IP address dynamically. Now, the responder needs to determine the security policy that is used to select the SAs from those proposed by the initiator. Unfortunately at this point the responder has no idea who the initiator is.. I can think of a few possible solutions: 1) the initiator only sends one choice so the responder cannot make a mistake, 2) the responder tries to guess the strongest proposed SAs, 3) use aggressive mode. Comments? -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Tue Dec 21 07:11:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15155; Tue, 21 Dec 1999 07:11:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16362 Tue, 21 Dec 1999 08:53:58 -0500 (EST) Message-ID: From: Jean Triquet To: "'ouyangyi'" , ipsec@lists.tislabs.com Subject: RE: tell me something about the frees/wan Date: Tue, 21 Dec 1999 08:52:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It supports both. -----Original Message----- From: ouyangyi [mailto:njouyang@263.net] Sent: December 20, 1999 9:43 PM To: ipsec@lists.tislabs.com Subject: tell me something about the frees/wan I have got the frees/wan software,but I don't know whether the frees/wan supprot the host-to-host or host-to-security gateway,please tell me .Thank you. From owner-ipsec@lists.tislabs.com Tue Dec 21 10:39:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17791; Tue, 21 Dec 1999 10:38:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16984 Tue, 21 Dec 1999 12:08:00 -0500 (EST) Message-ID: <60A30A0BD275D211B8F1006097E4728523BD68@mailgw.blockade.com> From: "Mason, Shane" To: "'Stephen Kent'" , francisco_corella@hp.com Cc: ipsec@lists.tislabs.com Subject: RE: A problem with public key encrption in IKE Date: Tue, 21 Dec 1999 12:12:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please help me understand. How is positive identification (authentication) not the same as nonrepudiability? If I positively identify someone (DNA?) how can they refute that they are that person? AFAIK, when someone says "You did it!", repudiation is the response "No I didn't." Non-repudiation is the state where the accuser has the ability to follow with "I have irrefutable proof." In IKE, there is non-repudiation. If anonymous party A uses IKE to set up an IPSEC session with party B, and all packets A sends are signed by A using the authentication key agreed upon in process of setting up the IPSEC session (using DH), then all of those packets had to come from A. B could impersonate A, but only to herself, so that doesn't count. We're not talking about legal authentication by an univolved third party, merely a way for B to KNOW that all packets for this session came from A. That is non-repudiation. It does not involve the identity of A other than A is the person with whom B initiated a session, and therefore these subsequest packets MUST be from A. A cannot deny that he sent the subsequent packets because, unless he shared the key with a third party. Similarly, if the crypto is strong,and the private key is safely locked away, if some-{one,thing} signs something, it is irrefutable that the owner of the signing key (whoever they are) signed it. Or are we asserting that non-repudiation is defined such that an uninvolved third party must be able to verify that A applied a signature? Or are we asserting that non-repudiation can only exist in cases of proving identity? ICMan -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, December 17, 1999 3:17 PM To: francisco_corella@hp.com Cc: ipsec@lists.tislabs.com Subject: Re: A problem with public key encrption in IKE Francisco, > Steve, > > If one is allowed to argue that one has been persuaded to sign >random data, then the whole concept of a digital signature >collapses. Remember that when a document is signed, the digital >signature is applied to a cryptographic hash of the document and >the hash is indistinguishable from random data if you don't know >how it was generated. Well, not all signatures are intended to be non-repudiable! Sometimes we sign things purely for authentication. As we have discussed extensively on the PKIX list, one should exercise care in setting the key usage bits, to distinguish the intent of signing as repudiable or non-repudiable. So, IF one wished to use signature-based authentication with IKE, and wished to avoid any connotation of non-repudiation, it is feasible to do that. Steve From owner-ipsec@lists.tislabs.com Tue Dec 21 10:39:03 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17804; Tue, 21 Dec 1999 10:39:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17022 Tue, 21 Dec 1999 12:13:22 -0500 (EST) Message-ID: <60A30A0BD275D211B8F1006097E4728523BD69@mailgw.blockade.com> From: "Mason, Shane" To: "'Hugo Krawczyk'" , Stephen Kent Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Subject: RE: signture mode and non-repudiation Date: Tue, 21 Dec 1999 12:18:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am definately missing something. When is repudiability (deniability_ useful? If I have an encrypted connection with someone, why would I want to allow someone to be able to muck with the data stream without my knowledge? ICMan -----Original Message----- From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] Sent: Monday, December 20, 1999 8:55 AM To: Stephen Kent Cc: francisco_corella@hp.com; ipsec@lists.tislabs.com Subject: signture mode and non-repudiation Stephen Kent wrote: > Well, not all signatures are intended to be non-repudiable! > Sometimes we sign things purely for authentication. As we have > discussed extensively on the PKIX list, one should exercise care in > setting the key usage bits, to distinguish the intent of signing as > repudiable or non-repudiable. So, IF one wished to use > signature-based authentication with IKE, and wished to avoid any > connotation of non-repudiation, it is feasible to do that. Even if a user U insists that his use of the signature mode does not provide non-repudiation (by usage bits or whatever means) still a person holding U's signature on the establishment of an ipsec SA can prove to a third party that U established that SA. This is not a issue of legal binding provided by the signature (and accepted by the signer) but a privacy or confidentiality issue of leaving your "fingerprints" in the places you visited in Internet. In general, I recommend to talk here about "deniability" (or undeniability) rather than non-repudiation (which has stronger legal connotations). In this context it is important to remark that providing non-repudiation of SA establishment is NOT a requirement of ipsec. To the contrary, it is to some extent a drawback of the signature mode (encryption mode deals better with this issue). Moreover, the signature mode of IKE has been designed to minimize the ``non-repudiation effect''. How? By letting the user of this mode (the signer) to find collisions in the input to the signature function. This is possible under certain instantiations of the prf function. To see this note that the values HASH (_I and _R) over which the signature is computed are the result of applying a prf to some data. A good choice of a prf could be, for example, 3DES in CBC-MAC mode. This would serve very well the purpose of the signature mode (i.e., as a strong authentication of the key-exchange) but will also allow the signer to claim that she signed a different message than the one she really did. (This is a good crypto class exercise: the user that knows the 3DES key used to produce HASH can easily find a different message that maps to the same output of the prf!) A collision like this may not be sufficient for the user to convince a journalist that he did not talk to some dubious party over the Internet, but will be enough to invalidate a legally acceptable non-repudiation property. On the other hand, if anyone insists in using the signature mode for non-repudiation purposes (I do not recommend that) then he can use a prf which is also collision resistant (e.g. HMAC-SHA1). Hugo From owner-ipsec@lists.tislabs.com Tue Dec 21 11:24:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18390; Tue, 21 Dec 1999 11:24:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17205 Tue, 21 Dec 1999 13:03:07 -0500 (EST) Message-Id: <199912211802.KAA18142@potassium.network-alchemy.com> To: "Mason, Shane" cc: "'Hugo Krawczyk'" , Stephen Kent , francisco_corella@hp.com, ipsec@lists.tislabs.com Subject: Re: signture mode and non-repudiation In-reply-to: Your message of "Tue, 21 Dec 1999 12:18:06 EST." <60A30A0BD275D211B8F1006097E4728523BD69@mailgw.blockade.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18139.945799340.1@network-alchemy.com> Date: Tue, 21 Dec 1999 10:02:20 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The encrypted nonce exchange (RSA or El-Gamal) provides repudiability but that doesn't mean that the data can be mucked with. Each side knows it is talking to an authenticated peer (via the ability of the peer to prove knowledge of its private key and decrypt the nonce) but neither side can later go to a 3rd party and prove it. There are lots of uses for something like this. Dan. On Tue, 21 Dec 1999 12:18:06 EST you wrote > I am definately missing something. When is repudiability (deniability_ > useful? If I have an encrypted connection with someone, why would I want to > allow someone to be able to muck with the data stream without my knowledge? > > ICMan > > -----Original Message----- > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Monday, December 20, 1999 8:55 AM > To: Stephen Kent > Cc: francisco_corella@hp.com; ipsec@lists.tislabs.com > Subject: signture mode and non-repudiation > > > Stephen Kent wrote: > > > Well, not all signatures are intended to be non-repudiable! > > Sometimes we sign things purely for authentication. As we have > > discussed extensively on the PKIX list, one should exercise care in > > setting the key usage bits, to distinguish the intent of signing as > > repudiable or non-repudiable. So, IF one wished to use > > signature-based authentication with IKE, and wished to avoid any > > connotation of non-repudiation, it is feasible to do that. > > Even if a user U insists that his use of the signature mode does not > provide non-repudiation (by usage bits or whatever means) still a person > holding U's signature on the establishment of an ipsec SA can prove to > a third party that U established that SA. This is not a issue of legal > binding provided by the signature (and accepted by the signer) but a > privacy or confidentiality issue of leaving your "fingerprints" in the > places you visited in Internet. > > In general, I recommend to talk here about "deniability" (or > undeniability) rather than non-repudiation (which has stronger legal > connotations). > > In this context it is important to remark that providing non-repudiation > of SA establishment is NOT a requirement of ipsec. To the contrary, > it is to some extent a drawback of the signature mode (encryption mode > deals better with this issue). > > Moreover, the signature mode of IKE has been designed to minimize the > ``non-repudiation effect''. > How? By letting the user of this mode (the signer) to find collisions in > the input to the signature function. This is possible under certain > instantiations of the prf function. > To see this note that the values HASH (_I and _R) over which the signature > is computed are the result of applying a prf to some data. > A good choice of a prf could be, for example, 3DES in CBC-MAC mode. > This would serve very well the purpose of the signature mode > (i.e., as a strong authentication of the key-exchange) but will also > allow the signer to claim that she signed a different message than the > one she really did. (This is a good crypto class exercise: the user that > knows the 3DES key used to produce HASH can easily find a different message > that maps to the same output of the prf!) > > A collision like this may not be sufficient for the user to convince a > journalist that he did not talk to some dubious party over the Internet, > but will be enough to invalidate a legally acceptable non-repudiation > property. > > On the other hand, if anyone insists in using the signature mode for > non-repudiation purposes (I do not recommend that) then he can use > a prf which is also collision resistant (e.g. HMAC-SHA1). > > Hugo From owner-ipsec@lists.tislabs.com Tue Dec 21 11:34:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18519; Tue, 21 Dec 1999 11:34:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17244 Tue, 21 Dec 1999 13:14:25 -0500 (EST) Message-ID: <60A30A0BD275D211B8F1006097E4728523BD6A@mailgw.blockade.com> From: "Mason, Shane" To: "'Dan Harkins'" , "Mason, Shane" Cc: "'Hugo Krawczyk'" , Stephen Kent , francisco_corella@hp.com, ipsec@lists.tislabs.com Subject: RE: signture mode and non-repudiation Date: Tue, 21 Dec 1999 13:19:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So non-repudiability and repudiability are defined as proof or lack of proof _to_be_taken_to_a_third_party_for_adjudication_? They have no meaning outside of a three+ party scenario? Are there words defined to describe the same feature for only the two parties involved in the exchange? Authenticated and Un-authenticated? ICMan -----Original Message----- From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] Sent: Tuesday, December 21, 1999 1:02 PM To: Mason, Shane Cc: 'Hugo Krawczyk'; Stephen Kent; francisco_corella@hp.com; ipsec@lists.tislabs.com Subject: Re: signture mode and non-repudiation The encrypted nonce exchange (RSA or El-Gamal) provides repudiability but that doesn't mean that the data can be mucked with. Each side knows it is talking to an authenticated peer (via the ability of the peer to prove knowledge of its private key and decrypt the nonce) but neither side can later go to a 3rd party and prove it. There are lots of uses for something like this. Dan. On Tue, 21 Dec 1999 12:18:06 EST you wrote > I am definately missing something. When is repudiability (deniability_ > useful? If I have an encrypted connection with someone, why would I want to > allow someone to be able to muck with the data stream without my knowledge? > > ICMan > > -----Original Message----- > From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] > Sent: Monday, December 20, 1999 8:55 AM > To: Stephen Kent > Cc: francisco_corella@hp.com; ipsec@lists.tislabs.com > Subject: signture mode and non-repudiation > > > Stephen Kent wrote: > > > Well, not all signatures are intended to be non-repudiable! > > Sometimes we sign things purely for authentication. As we have > > discussed extensively on the PKIX list, one should exercise care in > > setting the key usage bits, to distinguish the intent of signing as > > repudiable or non-repudiable. So, IF one wished to use > > signature-based authentication with IKE, and wished to avoid any > > connotation of non-repudiation, it is feasible to do that. > > Even if a user U insists that his use of the signature mode does not > provide non-repudiation (by usage bits or whatever means) still a person > holding U's signature on the establishment of an ipsec SA can prove to > a third party that U established that SA. This is not a issue of legal > binding provided by the signature (and accepted by the signer) but a > privacy or confidentiality issue of leaving your "fingerprints" in the > places you visited in Internet. > > In general, I recommend to talk here about "deniability" (or > undeniability) rather than non-repudiation (which has stronger legal > connotations). > > In this context it is important to remark that providing non-repudiation > of SA establishment is NOT a requirement of ipsec. To the contrary, > it is to some extent a drawback of the signature mode (encryption mode > deals better with this issue). > > Moreover, the signature mode of IKE has been designed to minimize the > ``non-repudiation effect''. > How? By letting the user of this mode (the signer) to find collisions in > the input to the signature function. This is possible under certain > instantiations of the prf function. > To see this note that the values HASH (_I and _R) over which the signature > is computed are the result of applying a prf to some data. > A good choice of a prf could be, for example, 3DES in CBC-MAC mode. > This would serve very well the purpose of the signature mode > (i.e., as a strong authentication of the key-exchange) but will also > allow the signer to claim that she signed a different message than the > one she really did. (This is a good crypto class exercise: the user that > knows the 3DES key used to produce HASH can easily find a different message > that maps to the same output of the prf!) > > A collision like this may not be sufficient for the user to convince a > journalist that he did not talk to some dubious party over the Internet, > but will be enough to invalidate a legally acceptable non-repudiation > property. > > On the other hand, if anyone insists in using the signature mode for > non-repudiation purposes (I do not recommend that) then he can use > a prf which is also collision resistant (e.g. HMAC-SHA1). > > Hugo From owner-ipsec@lists.tislabs.com Tue Dec 21 12:00:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18731; Tue, 21 Dec 1999 12:00:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17302 Tue, 21 Dec 1999 13:30:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <60A30A0BD275D211B8F1006097E4728523BD69@mailgw.blockade.com> References: <60A30A0BD275D211B8F1006097E4728523BD69@mailgw.blockade.com> Date: Tue, 21 Dec 1999 13:24:02 -0500 To: "Mason, Shane" From: Stephen Kent Subject: RE: signture mode and non-repudiation Cc: "'Hugo Krawczyk'" , francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shane, >I am definately missing something. When is repudiability (deniability_ >useful? If I have an encrypted connection with someone, why would I want to >allow someone to be able to muck with the data stream without my knowledge? > NR is subtly different from user or data authentication and data integrity. I suggest you look at the recent I-D security terminology glossary published by Rob Shirey, as a starting point. Steve From owner-ipsec@lists.tislabs.com Tue Dec 21 12:12:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18872; Tue, 21 Dec 1999 12:12:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17367 Tue, 21 Dec 1999 13:51:29 -0500 (EST) Message-Id: <199912211853.NAA05108@thunk.epilogue.com> From: Bill Sommerfeld To: "Mason, Shane" cc: "'Dan Harkins'" , "'Hugo Krawczyk'" , Stephen Kent , francisco_corella@hp.com, ipsec@lists.tislabs.com Subject: Re: signture mode and non-repudiation In-Reply-To: Message from "Mason, Shane" of "Tue, 21 Dec 1999 13:19:07 EST." <60A30A0BD275D211B8F1006097E4728523BD6A@mailgw.blockade.com> Date: Tue, 21 Dec 1999 13:53:08 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > So non-repudiability and repudiability are defined as proof or lack of proof > _to_be_taken_to_a_third_party_for_adjudication_? They have no meaning > outside of a three+ party scenario? Cryptography isn't needed in a <3 party scenario. - Bill From owner-ipsec@lists.tislabs.com Tue Dec 21 15:38:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21130; Tue, 21 Dec 1999 15:38:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18127 Tue, 21 Dec 1999 17:16:13 -0500 (EST) Message-ID: From: Jean Triquet To: "'Bill Sommerfeld'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: signture mode and non-repudiation Date: Tue, 21 Dec 1999 17:04:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ??? >> Cryptography isn't needed in a <3 party scenario. Please explain this one. -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@orchard.arlington.ma.us] Sent: December 21, 1999 1:53 PM To: Mason, Shane Cc: 'Dan Harkins'; 'Hugo Krawczyk'; Stephen Kent; francisco_corella@hp.com; ipsec@lists.tislabs.com Subject: Re: signture mode and non-repudiation > So non-repudiability and repudiability are defined as proof or lack of proof > _to_be_taken_to_a_third_party_for_adjudication_? They have no meaning > outside of a three+ party scenario? Cryptography isn't needed in a <3 party scenario. - Bill From owner-ipsec@lists.tislabs.com Tue Dec 21 17:01:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21933; Tue, 21 Dec 1999 17:01:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18268 Tue, 21 Dec 1999 18:26:08 -0500 (EST) Message-Id: <199912212224.RAA09383@thunk.epilogue.com> From: Bill Sommerfeld To: Jean Triquet cc: "'Bill Sommerfeld'" , "'ipsec@lists.tislabs.com'" Subject: Re: signture mode and non-repudiation In-Reply-To: Message from Jean Triquet of "Tue, 21 Dec 1999 17:04:16 EST." Date: Tue, 21 Dec 1999 17:24:47 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> Cryptography isn't needed in a <3 party scenario. > > Please explain this one. I'm including attackers/adversaries in the count of parties. - Bill From owner-ipsec@lists.tislabs.com Tue Dec 21 19:19:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06468; Tue, 21 Dec 1999 19:19:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA18625 Tue, 21 Dec 1999 20:52:47 -0500 (EST) Message-ID: <38603025.31A58DA2@263.net> Date: Wed, 22 Dec 1999 09:57:58 +0800 From: ouyangyi X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jean Triquet CC: "ipsec@lists.tislabs.com" Subject: Re: tell me something about the frees/wan References: Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have seen the RFC2401.It mentions that the implementation of IPSEC should offer protection against replays and limited traffic flow confidentiality.I want to know how does FREES/WAN implement them and where is the FREES/WAN's SPD.How does FREES/WAN define SA? The last question is where does the FREES/WAN implement?(I mean that whether it use a. Integration of IPsec into the native IP implementation or b. "Bump-in-the-stack" (BITS) implementations.) Jean Triquet wrote: > It supports both. > > -----Original Message----- > From: ouyangyi [mailto:njouyang@263.net] > Sent: December 20, 1999 9:43 PM > To: ipsec@lists.tislabs.com > Subject: tell me something about the frees/wan > > I have got the frees/wan software,but I don't know whether the > frees/wan supprot the host-to-host or host-to-security gateway,please > tell me .Thank you. From owner-ipsec@lists.tislabs.com Tue Dec 21 20:59:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA18402; Tue, 21 Dec 1999 20:59:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18731 Tue, 21 Dec 1999 22:08:55 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Tue, 21 Dec 1999 19:10:45 -0800 Message-Id: In-Reply-To: <385B9D44.C57AE522@ix.netcom.com> Subject: Re: A problem with public key encrption in IKE MIME-Version: 1.0 To: ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, << Of course, you are right, and this is how the ID PFS requirement should be specified. Another issue which occurs to me is that phase 2 IDs with respect to authentication are currently tied to the phase 1 SA. If a security gateway (sgw) is to provide individualized authentication for hosts which it protects, it must use unique IDs for phase 1. These IDs must be tied to the phase 2 SAs which they authenticate, and I think this means that phase 1 configuration is tied to phase 2 configuration. Do you have a model which simplifies this? >> What do you mean by "individualized authentication"? What are the unique IDs? You cannot authenticate a host that's behind a sgw by conducting phase 1 exchange with the sgw. All you can do is, in phase 2, initiate a quick mode and send an SA proposal for a specific client identified by Idi2 (using the notations of the 5/99 Ike draft). I believe you can initiate different quick modes with different proposals for different clients, all protected by the same phase 1 SA. If you want to authenticate a host "behind" the sgw then you have to talk directly to that host. You could do that through a tunnel that you have previously set up with the sgw, e.g. if you want to avoid disclosing the IP address of the host. << One other option that may be provided at the phase 2 (negotiation) level is key PFS. While I agree to some extent with your assertion, I think that you imply that every phase 1 SA should provide for key PFS automatically. Is this right? >> Why would I imply that? Key PFS is also a phase 2 feature that can be selected or not selected after phase 1 has determined the identity of the peer. Btw, how does one negotiate key PFS? It seems that the quick mode initiator dictates whether key PFS is used or not by sending or not sending the KE payload. Is that right? Francisco From owner-ipsec@lists.tislabs.com Tue Dec 21 21:29:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20617; Tue, 21 Dec 1999 21:29:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18848 Tue, 21 Dec 1999 22:52:47 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Tue, 21 Dec 1999 19:56:39 -0800 Message-Id: In-Reply-To: <385F63C4.4B1F53ED@F-Secure.com> Subject: Re: MM with signatures and dynamic IP addresses? MIME-Version: 1.0 To: Ari.Huttunen@F-Secure.com Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="MM" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari, We were just discussing pretty much this same issue in another thread. The issue also arises in other scenarios, and there are cases where the initiator rather than the responder faces the issue. For example: (*) The responder has a dynamically assigned IP address. The initiator is a security gateway negociating on behalf of a client. The client knows the dynamically assigned IP address of the responder, but the gateway does not. The client requests the establishment of a phase 2 SA with that IP address. The gateway must first set up a phase 1 SA with that address, but does not know who it is talking to until it has received the ID payload from the responder during the phase 1 exchange. (*) The responder has a perfectly normal statically assigned IP address. The intiator is a gateway with a policy for the responder, but the policy is indexed by the distinguished name of the responder rather than by the IP address. A client of the gateway requests an SA with the IP address of the responder, and the rest is as above. Notice that the above two cases cannot be solved by the use of aggressive mode. In my opinion, the solution to this is very simple: have a policy for phase 1 that is independent of the peer. After all, one of the roles of phase 1 is to find out the identity of the peer, so it does not make sense to make phase 1 policy dependent on who the peer is. I believe this solution is consistent with RFC 2401. Perhaps it is even the behavior that was intended by the authors of RFC 2401. Am I right? In any event, a clarification in RFC 2401 would be useful. Francisco Corella (francisco_corella@hp.com) ______________________________ Reply Separator _________________________________ Subject: MM with signatures and dynamic IP addresses? Author: Non-HP-Ari.Huttunen (Ari.Huttunen@F-Secure.com) at HP-ColSprings,mimegw5 Date: 12/21/99 3:25 AM What is the responder supposed to do in the following scenario: Main mode with signature authentication is being used and the initiator chooses the IP address dynamically. Now, the responder needs to determine the security policy that is used to select the SAs from those proposed by the initiator. Unfortunately at this point the responder has no idea who the initiator is.. I can think of a few possible solutions: 1) the initiator only sends one choice so the responder cannot make a mistake, 2) the responder tries to guess the strongest proposed SAs, 3) use aggressive mode. Comments? -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Tue Dec 21 21:58:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22016; Tue, 21 Dec 1999 21:58:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA18871 Tue, 21 Dec 1999 23:17:42 -0500 (EST) Message-ID: From: Jean Triquet To: "'ouyangyi'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: tell me something about the frees/wan Date: Tue, 21 Dec 1999 23:07:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="big5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The best way to get answers on freeS/WAN architecture would be to ask the developers through freeS/WAN's own mail list at linux-ipsec@clinet.fi. I'm not one of the developer so, here are some TENTATIVE answers. >>...the implementation of IPSEC should offer protection against replays and limited traffic flow confidentiality.I want to know how does FREES/WAN implement them...<< Replay protection is there but I don't know the implementation details...yet... Limited traffic flow confidentiality is done through tunneling, for the final source and destination addresses. In regards of the amount of traffic exchanged, I don't know if packets padding is implemented. >>...where is the FREES/WAN's SPD.<< The Security Policy Database is in a file called ipsec.conf. All the policies are listed in there. >> How does FREES/WAN define SA? << If you mean "How does freeS/WAN creates an SA", then it uses the IKE protocol specifications (through a daemon called Pluto) to perform the negotiations and key management. The key management actually supports -manually keyed (keys exchanged manually through email or whatever) -automatically keyed through shared secrets or RSA signatures for authentication >>...where does the FREES/WAN implement?<< freeS/WAN would fit the profile of a Bump-in-the-stack implementation. It adds virtual network interface(s) to the system. Seen through the eyes of ifconfig... more info where you probably got the software at www.freeswan.org Regards, Jean Triquet -----Original Message----- From: ouyangyi [mailto:njouyang@263.net] Sent: December 21, 1999 8:58 PM To: Jean Triquet Cc: ipsec@lists.tislabs.com Subject: Re: tell me something about the frees/wan I have seen the RFC2401.It mentions that the implementation of IPSEC should offer protection against replays and limited traffic flow confidentiality.I want to know how does FREES/WAN implement them and where is the FREES/WAN's SPD.How does FREES/WAN define SA? The last question is where does the FREES/WAN implement?(I mean that whether it use a. Integration of IPsec into the native IP implementation or b. "Bump-in-the-stack" (BITS) implementations.) Jean Triquet wrote: > It supports both. > > -----Original Message----- > From: ouyangyi [mailto:njouyang@263.net] > Sent: December 20, 1999 9:43 PM > To: ipsec@lists.tislabs.com > Subject: tell me something about the frees/wan > > I have got the frees/wan software,but I don't know whether the > frees/wan supprot the host-to-host or host-to-security gateway,please > tell me .Thank you. From owner-ipsec@lists.tislabs.com Wed Dec 22 08:47:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20761; Wed, 22 Dec 1999 08:47:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00262 Wed, 22 Dec 1999 09:50:28 -0500 (EST) Message-ID: <60A30A0BD275D211B8F1006097E4728523BD6F@mailgw.blockade.com> From: "Mason, Shane" To: "'Bill Sommerfeld'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: signture mode and non-repudiation Date: Wed, 22 Dec 1999 09:54:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When I asked my original question, it was to determine if the definition of non-repuduiation REQUIRED a third party verification. I was answered in the affirmative. So, for authentication, you simply need to verify the identity of someone talking to you, or that the person that started talking to you is still the same person. For non-repudiation, I must be able to tell the identity of the person you are talking to, or I must be able to determine that you are still talking to the person with whom you initiated conversation. Or perhaps "non-repudiation is the ability to provide proof of authentication to an otherwise uninvolved third party." Have I got this correct? ICMan -----Original Message----- From: Bill Sommerfeld [mailto:sommerfeld@orchard.arlington.ma.us] Sent: Tuesday, December 21, 1999 5:25 PM To: Jean Triquet Cc: 'Bill Sommerfeld'; 'ipsec@lists.tislabs.com' Subject: Re: signture mode and non-repudiation > >> Cryptography isn't needed in a <3 party scenario. > > Please explain this one. I'm including attackers/adversaries in the count of parties. - Bill From owner-ipsec@lists.tislabs.com Wed Dec 22 09:46:19 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21376; Wed, 22 Dec 1999 09:46:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00719 Wed, 22 Dec 1999 11:17:28 -0500 (EST) Message-ID: <3860FB22.39A69184@redcreek.com> Date: Wed, 22 Dec 1999 08:24:02 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: francisco_corella@hp.com CC: ipsec@lists.tislabs.com Subject: Re: A problem with public key encrption in IKE (long) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francisco, francisco_corella@hp.com wrote: > > Scott, > > << > Of course, you are right, and this is how the ID PFS requirement > should be specified. Another issue which occurs to me is that > phase 2 IDs with respect to authentication are currently tied to > the phase 1 SA. If a security gateway (sgw) is to provide > individualized authentication for hosts which it protects, it > must use unique IDs for phase 1. These IDs must be tied to the > phase 2 SAs which they authenticate, and I think this means that > phase 1 configuration is tied to phase 2 configuration. Do you > have a model which simplifies this? > >> > > What do you mean by "individualized authentication"? What are the > unique IDs? > The unique IDs may be DNs which are tied to particular hosts behind the sgw. > You cannot authenticate a host that's behind a sgw by conducting phase 1 > exchange with the sgw. I disagree. It is possible to configure the sgw to represent (in an authenticated manner) hosts which it protects in at least 2 ways: first, the sgw may be configured with a private key and a matching cert containing the protected endpoint's DN. This implies that the responder trusts the sgw to act on the endpoint's behalf in this regard. A second way is to bind attribute certs containing authorization info for specific endpoints into the sgw's identity cert. In the first case, individual phase 1 SAs are required for each phase 2 identity. In the second case, a single phase 1 SA could conceivably be used for any phase 2 SA, provided that the phase 2 SAs did not require PFS. As far as I know, currently deployed IKE implementations mostly support only the first case. > All you can do is, in phase 2, initiate a quick > mode and send an SA proposal for a specific client identified by Idi2 > (using the notations of the 5/99 Ike draft). I believe you can initiate > different quick modes with different proposals for different clients, > all protected by the same phase 1 SA. > > If you want to authenticate a host "behind" the sgw then you have to > talk directly to that host. You could do that through a tunnel that you > have previously set up with the sgw, e.g. if you want to avoid > disclosing the IP address of the host. See above. > > << > One other option that may be provided at the phase 2 > (negotiation) level is key PFS. While I agree to some extent with > your assertion, I think that you imply that every phase 1 SA > should provide for key PFS automatically. Is this right? > >> > > Why would I imply that? Key PFS is also a phase 2 feature that can be > selected or not selected after phase 1 has determined the identity of the > peer. I was (mis)interpreting the following comment: > Every phase 1 SA should provide sufficient protection to protect > negociation of any phase 2 SA that may have to be established. I think you are correct that key pfs could be provided by a given phase 1 SA on an ad hoc basis, with the caveat that once provided, at minimum one additional KE payload would be required to service the next phase 2 consumer (since the one sent on behalf of the PFS consumer could not be re-used). Scott From owner-ipsec@lists.tislabs.com Wed Dec 22 09:50:58 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21412; Wed, 22 Dec 1999 09:50:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00816 Wed, 22 Dec 1999 11:44:17 -0500 (EST) Message-ID: <3861016A.BFE3FB8B@redcreek.com> Date: Wed, 22 Dec 1999 08:50:50 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: francisco_corella@hp.com CC: Ari.Huttunen@F-Secure.com, ipsec@lists.tislabs.com Subject: Re: MM with signatures and dynamic IP addresses? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francisco, francisco_corella@hp.com wrote: > > Ari, > > We were just discussing pretty much this same issue in another thread. > > The issue also arises in other scenarios, and there are cases where the > initiator rather than the responder faces the issue. For example: > > (*) The responder has a dynamically assigned IP address. The initiator is a > security gateway negociating on behalf of a client. The client knows the > dynamically assigned IP address of the responder, but the gateway does not. The > client requests the establishment of a phase 2 SA with that IP address. The > gateway must first set up a phase 1 SA with that address, but does not know who > it is talking to until it has received the ID payload from the responder during > the phase 1 exchange. > > (*) The responder has a perfectly normal statically assigned IP address. The > intiator is a gateway with a policy for the responder, but the policy is indexed > by the distinguished name of the responder rather than by the IP address. A > client of the gateway requests an SA with the IP address of the responder, and > the rest is as above. > > Notice that the above two cases cannot be solved by the use of aggressive mode. For both of these cases, how does the client request the establishment of a phase 2 SA with that IP address? If this is done via some sort of signalling protocol, then perhaps the client could give some identity information along with its request. The case where the negotiation is activated by the sgw's receipt of a packet from the client to the responder is less clear. If aggressive (or base) mode were used, it is possible that that the intitiator would discover upon receipt of the responder's SA+ID payloads that the selected parameters are not acceptable, but recovery would not be too complex: fail the negotiation and re-initiate based upon the supplied ID. However, see further comments below. > In my opinion, the solution to this is very simple: have a policy for phase 1 > that is independent of the peer. After all, one of the roles of phase 1 is to > find out the identity of the peer, so it does not make sense to make phase 1 > policy dependent on who the peer is. Now I see where you've been going (at least, now that we've arrived :-)). I think I like this, but there is still the issue with the binding of the IDs to the phase 1 SA that I mentioned earlier. However, this is resolved by the use of one sgw ID cert with bindings authorizing the sgw to represent specific endpoints. In that case, authorized phase 2 IDs (DNs, etc) are included in the phase 2 ID payload, so that one duly authorized phase 1 SA may be used for any/all of them provided that PFS is not required. I should note that the sgw cert+bindings is not my own idea, and that I gleaned it from an off-list email exchange. > I believe this solution is consistent with RFC 2401. Perhaps it is even the > behavior that was intended by the authors of RFC 2401. Am I right? In any > event, a clarification in RFC 2401 would be useful. I also believe that this is consistent with RFC2401. Scott From owner-ipsec@lists.tislabs.com Wed Dec 22 13:04:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23879; Wed, 22 Dec 1999 13:04:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02653 Wed, 22 Dec 1999 14:33:35 -0500 (EST) Message-ID: <23E9E6DBBF4DD21190BC006008B0213E02CBF56D@newman.verisign.com> From: Alex Deacon To: "'ipsec@lists.tislabs.com'" Subject: Workshop CA's..... Date: Tue, 21 Dec 1999 15:20:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those of you attending the next IPSec workshop in San Diego, I wanted to remind you that the VeriSign Test CA's are still available. See https://onsite-test-fe.bbtest.net/bakeoff/ for details. Alex From owner-ipsec@lists.tislabs.com Wed Dec 22 14:18:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25121; Wed, 22 Dec 1999 14:18:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02621 Wed, 22 Dec 1999 14:25:51 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Wed, 22 Dec 1999 11:29:46 -0800 Message-Id: In-Reply-To: <3860FB22.39A69184@redcreek.com> Subject: Re: A problem with public key encrption in IKE (long) MIME-Version: 1.0 To: skelly@redcreek.com Cc: francisco_corella@hp.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, << > You cannot authenticate a host that's behind a sgw by conducting phase 1 > exchange with the sgw. I disagree. It is possible to configure the sgw to represent (in an authenticated manner) hosts which it protects in at least 2 ways: first, the sgw may be configured with a private key and a matching cert containing the protected endpoint's DN. This implies that the responder trusts the sgw to act on the endpoint's behalf in this regard. A second way is to bind attribute certs containing authorization info for specific endpoints into the sgw's identity cert. >> OK. << In the first case, individual phase 1 SAs are required for each phase 2 identity. In the second case, a single phase 1 SA could conceivably be used for any phase 2 SA, provided that the phase 2 SAs did not require PFS. As far as I know, currently deployed IKE implementations mostly support only the first case. >> Notice that, in the first case, you can still use the same policy for the individual phase 1 SAs, and then choose the phase 2 policy after phase 1 has revealed the identity of the peer. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: A problem with public key encrption in IKE (long) Author: Non-HP-skelly (skelly@redcreek.com) at HP-ColSprings,mimegw5 Date: 12/22/99 8:24 AM Hi Francisco, francisco_corella@hp.com wrote: > > Scott, > > << > Of course, you are right, and this is how the ID PFS requirement > should be specified. Another issue which occurs to me is that > phase 2 IDs with respect to authentication are currently tied to > the phase 1 SA. If a security gateway (sgw) is to provide > individualized authentication for hosts which it protects, it > must use unique IDs for phase 1. These IDs must be tied to the > phase 2 SAs which they authenticate, and I think this means that > phase 1 configuration is tied to phase 2 configuration. Do you > have a model which simplifies this? > >> > > What do you mean by "individualized authentication"? What are the > unique IDs? > The unique IDs may be DNs which are tied to particular hosts behind the sgw. > You cannot authenticate a host that's behind a sgw by conducting phase 1 > exchange with the sgw. I disagree. It is possible to configure the sgw to represent (in an authenticated manner) hosts which it protects in at least 2 ways: first, the sgw may be configured with a private key and a matching cert containing the protected endpoint's DN. This implies that the responder trusts the sgw to act on the endpoint's behalf in this regard. A second way is to bind attribute certs containing authorization info for specific endpoints into the sgw's identity cert. In the first case, individual phase 1 SAs are required for each phase 2 identity. In the second case, a single phase 1 SA could conceivably be used for any phase 2 SA, provided that the phase 2 SAs did not require PFS. As far as I know, currently deployed IKE implementations mostly support only the first case. > All you can do is, in phase 2, initiate a quick > mode and send an SA proposal for a specific client identified by Idi2 > (using the notations of the 5/99 Ike draft). I believe you can initiate > different quick modes with different proposals for different clients, > all protected by the same phase 1 SA. > > If you want to authenticate a host "behind" the sgw then you have to > talk directly to that host. You could do that through a tunnel that you > have previously set up with the sgw, e.g. if you want to avoid > disclosing the IP address of the host. See above. > > << > One other option that may be provided at the phase 2 > (negotiation) level is key PFS. While I agree to some extent with > your assertion, I think that you imply that every phase 1 SA > should provide for key PFS automatically. Is this right? > >> > > Why would I imply that? Key PFS is also a phase 2 feature that can be > selected or not selected after phase 1 has determined the identity of the > peer. I was (mis)interpreting the following comment: > Every phase 1 SA should provide sufficient protection to protect > negociation of any phase 2 SA that may have to be established. I think you are correct that key pfs could be provided by a given phase 1 SA on an ad hoc basis, with the caveat that once provided, at minimum one additional KE payload would be required to service the next phase 2 consumer (since the one sent on behalf of the PFS consumer could not be re-used). Scott From owner-ipsec@lists.tislabs.com Wed Dec 22 14:22:46 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25178; Wed, 22 Dec 1999 14:22:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02693 Wed, 22 Dec 1999 14:45:32 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Wed, 22 Dec 1999 11:49:25 -0800 Message-Id: In-Reply-To: <3861016A.BFE3FB8B@redcreek.com> Subject: Re: MM with signatures and dynamic IP addresses? MIME-Version: 1.0 To: skelly@redcreek.com Cc: francisco_corella@hp.com, Ari.Huttunen@F-Secure.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, << Now I see where you've been going (at least, now that we've arrived :-)). << I'm delighted to see that we understand each other :-) >> I think I like this, but there is still the issue with the binding of the IDs to the phase 1 SA that I mentioned earlier. >> As I said in the other thread, I don't see what the issue is. You can have a single phase 1 policy even if you and/or your peer have multiple phase 1 IDs. << However, this is resolved by the use of one sgw ID cert with bindings authorizing the sgw to represent specific endpoints. In that case, authorized phase 2 IDs (DNs, etc) are included in the phase 2 ID payload, so that one duly authorized phase 1 SA may be used for any/all of them provided that PFS is not required. I should note that the sgw cert+bindings is not my own idea, and that I gleaned it from an off-list email exchange. >> The way I interpret the Ike spec, the security gateway is simply trusted to act on behalf of its clients and to vouch for the identity of its clients, without any cryptographic delegation of authority. But one could do what you say if that trust is not there. In any event, I think this is orthogonal to the question of whether it is OK to have only one policy for phase 1, independent of the identity of the peer. Francisco ______________________________ Reply Separator _________________________________ Subject: Re: MM with signatures and dynamic IP addresses? Author: Non-HP-skelly (skelly@redcreek.com) at HP-ColSprings,mimegw5 Date: 12/22/99 8:50 AM Hi Francisco, francisco_corella@hp.com wrote: > > Ari, > > We were just discussing pretty much this same issue in another thread. > > The issue also arises in other scenarios, and there are cases where the > initiator rather than the responder faces the issue. For example: > > (*) The responder has a dynamically assigned IP address. The initiator is a > security gateway negociating on behalf of a client. The client knows the > dynamically assigned IP address of the responder, but the gateway does not. T he > client requests the establishment of a phase 2 SA with that IP address. The > gateway must first set up a phase 1 SA with that address, but does not know wh o > it is talking to until it has received the ID payload from the responder durin g > the phase 1 exchange. > > (*) The responder has a perfectly normal statically assigned IP address. The > intiator is a gateway with a policy for the responder, but the policy is index ed > by the distinguished name of the responder rather than by the IP address. A > client of the gateway requests an SA with the IP address of the responder, and > the rest is as above. > > Notice that the above two cases cannot be solved by the use of aggressive mode . For both of these cases, how does the client request the establishment of a phase 2 SA with that IP address? If this is done via some sort of signalling protocol, then perhaps the client could give some identity information along with its request. The case where the negotiation is activated by the sgw's receipt of a packet from the client to the responder is less clear. If aggressive (or base) mode were used, it is possible that that the intitiator would discover upon receipt of the responder's SA+ID payloads that the selected parameters are not acceptable, but recovery would not be too complex: fail the negotiation and re-initiate based upon the supplied ID. However, see further comments below. > In my opinion, the solution to this is very simple: have a policy for phase 1 > that is independent of the peer. After all, one of the roles of phase 1 is to > find out the identity of the peer, so it does not make sense to make phase 1 > policy dependent on who the peer is. Now I see where you've been going (at least, now that we've arrived :-)). I think I like this, but there is still the issue with the binding of the IDs to the phase 1 SA that I mentioned earlier. However, this is resolved by the use of one sgw ID cert with bindings authorizing the sgw to represent specific endpoints. In that case, authorized phase 2 IDs (DNs, etc) are included in the phase 2 ID payload, so that one duly authorized phase 1 SA may be used for any/all of them provided that PFS is not required. I should note that the sgw cert+bindings is not my own idea, and that I gleaned it from an off-list email exchange. > I believe this solution is consistent with RFC 2401. Perhaps it is even the > behavior that was intended by the authors of RFC 2401. Am I right? In any > event, a clarification in RFC 2401 would be useful. I also believe that this is consistent with RFC2401. Scott From owner-ipsec@lists.tislabs.com Wed Dec 22 14:52:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25557; Wed, 22 Dec 1999 14:52:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03123 Wed, 22 Dec 1999 16:39:26 -0500 (EST) Message-ID: <3861462F.FDA2CEFA@redcreek.com> Date: Wed, 22 Dec 1999 13:44:15 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: francisco_corella@hp.com CC: Ari.Huttunen@F-Secure.com, ipsec@lists.tislabs.com Subject: Re: MM with signatures and dynamic IP addresses? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francisco, francisco_corella@hp.com wrote: > The way I interpret the Ike spec, the security gateway is simply trusted to act > on behalf of its clients and to vouch for the identity of its clients, without > any cryptographic delegation of authority. But one could do what you say if > that trust is not there. I think that there must be some implied delegation. The problem here is that if we don't provide some delegation mechanism, we run the risk that some sgw may claim to represent an endpoint with access to our network, and that someone may now put (spoofed) packets into the tunnel. That sgw may be one that is granted access for some purpose, but that we do not expect to represent the particular endpoint that it subsequently impersonates. Nobody else (e.g routers along the way) can see that this is occurring. One way to provide for such delegation is to configure, as part of the phase 2 requirements, some phase 1 requirements including phase 1 identities. > In any event, I think this is orthogonal to the > question of whether it is OK to have only one policy for phase 1, independent of > the identity of the peer. By "one policy for phase 1" do you refer only to cryptographic parameters (and not identities or authentication mechanisms), i.e all phase 1 SAs use 3DES/SHA1? Scott From owner-ipsec@lists.tislabs.com Thu Dec 23 05:25:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07773; Thu, 23 Dec 1999 05:25:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04846 Thu, 23 Dec 1999 06:32:30 -0500 (EST) Message-Id: <199912231136.GAA20051@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-hybrid-auth-03.txt Date: Thu, 23 Dec 1999 06:36:26 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-03.txt Pages : 10 Date : 22-Dec-99 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectionally authenticated. To make this IKE bi-directionally authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid Authentication mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-hybrid-auth-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-isakmp-hybrid-auth-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: <19991222095631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991222095631.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Dec 23 18:02:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17227; Thu, 23 Dec 1999 18:02:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06791 Thu, 23 Dec 1999 19:37:12 -0500 (EST) From: francisco_corella@hp.com X-OpenMail-Hops: 1 Date: Thu, 23 Dec 1999 16:41:07 -0800 Message-Id: In-Reply-To: <3861462F.FDA2CEFA@redcreek.com> Subject: Re: MM with signatures and dynamic IP addresses? MIME-Version: 1.0 To: skelly@redcreek.com Cc: francisco_corella@hp.com, Ari.Huttunen@F-Secure.com, ipsec@lists.tislabs.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="Re:" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, << I think that there must be some implied delegation. The problem here is that if we don't provide some delegation mechanism, we run the risk that some sgw may claim to represent an endpoint with access to our network, and that someone may now put (spoofed) packets into the tunnel. That sgw may be one that is granted access for some purpose, but that we do not expect to represent the particular endpoint that it subsequently impersonates. Nobody else (e.g routers along the way) can see that this is occurring. >> I'm not sure I understand all the details of the scenario you are describing. Here are two comments (which may not be applicable if I have misunderstood): (*) If the endpoint trusts the sgw sufficiently to delegate its capabilities to it, why wouldn't the peer that is negociating with the sgw trust the sgw? (*) Wouldn't it be simpler set up a tunnel to the sgw, and then go through that tunnel to reach the endpoint and do an IKE exchange directly with the endpoint? << By "one policy for phase 1" do you refer only to cryptographic parameters (and not identities or authentication mechanisms), i.e all phase 1 SAs use 3DES/SHA1? >> I refer to all the attributes that can be negociated in phase 1 using the SA payload and associated proposal and transform payloads. These attributes are listed in Appendix A of the 5/99 Ike draft. In particular, that includes the authentication mechanism. For example, an ipsec administrator of an ipsec peer that implements preshared keys and signatures would have four choices for the phase 1 policy concerning the authentication mechanism: (1) Use either preshared keys or signatures, with preshared keys preferred over signatures (2) Use either preshared keys or signatures, with signatures preferred over preshared keys (3) Use only preshared keys (4) Use only signatures Now suppose there are two such ipsec peers, and option (1) has been chosen for both of them. Then the initiator will propose preshared keys as first choice, and signatures as second choice. The responder also prefers preshared keys. However, the responder should first look up its database of preshared keys and check that it has a preshared key with the initiator. If this is not the case, then the responder should choose signatures instead. Can the responder do the preshared key lookup? It definitely can in aggressive mode, since it has already received the Idi1 payload in message 1 by the time it has to send the SA payload in message 2. In main mode, on the other hand, the responder does not receive the Idi1 payload until message 5. But that's ok, because in main mode with preshared keys, the source IP addresses are supposed to be used for identification instead of the ID payloads. The responder will use the source IP address of the initiator to look up the database of preshared keys. If a preshared key is not found for the source IP address of the initiator, then the responder will choose signatures instead. Authentication will then use the ID payloads exchanged in messages 5 and 6. (By the way, that would not be ok if my recent proposal or other earlier proposals to fix main mode with preshared keys had been accepted. So this could be an argument against those proposals. I'm now thinking that the best thing to do about main mode with preshared keys would be to drop it altogether, since it does not seem to serve any useful purpose. The advantage of main mode over aggressive mode is that it provides identity protection, but that advantage goes away if the identity is the source IP address. So why use main mode, which takes six messages, when aggressive mode does the same job with only three messages?) Francisco ______________________________ Reply Separator _________________________________ Subject: Re: MM with signatures and dynamic IP addresses? Author: Non-HP-skelly (skelly@redcreek.com) at HP-ColSprings,mimegw5 Date: 12/22/99 1:44 PM Hi Francisco, francisco_corella@hp.com wrote: > The way I interpret the Ike spec, the security gateway is simply trusted to ac t > on behalf of its clients and to vouch for the identity of its clients, without > any cryptographic delegation of authority. But one could do what you say if > that trust is not there. I think that there must be some implied delegation. The problem here is that if we don't provide some delegation mechanism, we run the risk that some sgw may claim to represent an endpoint with access to our network, and that someone may now put (spoofed) packets into the tunnel. That sgw may be one that is granted access for some purpose, but that we do not expect to represent the particular endpoint that it subsequently impersonates. Nobody else (e.g routers along the way) can see that this is occurring. One way to provide for such delegation is to configure, as part of the phase 2 requirements, some phase 1 requirements including phase 1 identities. > In any event, I think this is orthogonal to the > question of whether it is OK to have only one policy for phase 1, independent of > the identity of the peer. By "one policy for phase 1" do you refer only to cryptographic parameters (and not identities or authentication mechanisms), i.e all phase 1 SAs use 3DES/SHA1? Scott