I'm ok with Dave's proposed text, with or without Tero's proposed changes.
Apologies for missing the fact that it is not strictly man-in-the-middle attack. Certainly the attacker won't be able to take advantage of the revelation if he is not in the middle, but it's still improper to reveal the token. I share Tero's concern with the general usefulness of Section 5.2. I think it's fine to keep it there, but I agree that his "made impossible" observation is absolutely essential for its use. That was the motivation behind my "important to note," although I am ok with removing that phrase. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Paul Hoffman <paul.hoff...@vpnc.org> Cc: ipsec@ietf.org Date: 02/14/2011 08:14 AM Subject: Re: [IPsec] Failure Detection - issue #202 Sent by: ipsec-boun...@ietf.org Paul Hoffman writes: > > A token maker MUST NOT send a QCD token in an unprotected > > message for an existing IKE SA. > > > > This requirement is obvious and easy in the case of a single gateway. > > However, some implementations use a load balancer to divide the load > > between several physical gateways. In such configuration it MUST NOT > > be possible to trick one gateway into sending a QCD token for an > > IKE SA which exists on another gateway. This is true whether the > > an attacker uses the token taker's IP address or a different IP > > address. > > > > Because it includes the token taker's IP address in the token > > generation, the method in Section 5.2 prevents revealing the QCD > > token for an existing pair of IKE SPIs to an attacker who is using a > > different IP address. I think this paragraph should be reformatted to include Section 5.2 in the beginning, so it would emphasize that this is case 1, i.e: The method in Section 5.2 prevents revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address by including the token taker's IP addres in the token generation. > > Note that the use of this method causes the > > tokens to be invalidated whenever the token taker's address changes. I am not sure that this paragraph belongs here, as it should already be mentioned in the section 5.2 and this is not a security issue.. I would remove the whole paragraph. > > It is also important to note that this method does not prevent > > revealing the QCD token to a man-in-the-middle attacker who is > > spoofing the token taker's IP address. Such an attacker may attempt > > to direct messages to a cluster member other than the member > > responsible for the IKE SA in an attempt to trick that gateway into > > sending a QCD token for an existing IKE SA. I think removing things like "It is also important to note ..." type of text, as they do not really help understanding the problem, i.e: This method does not prevent revealing the QCD token to a active attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for the IKE SA in an attempt to trick that gateway into sending QCD token for an existing IKE SA. (Also replaced man-in-the-middle as the attacker is not necessarely man-in-the-middle (http://en.wikipedia.org/wiki/Man-in-the-middle_attack) but instead simply active attacker sending faked packets). > > IPsec Failure Detection is not applicable to deployments where the QCD > > token is shared by multiple gateways and the gateways cannot assess > > whether the token can be legitimately sent in the clear while another > > gateway may actually still own the SA's. Load balancer configurations > > typically fall in this category. In order for a load balancing > > configuration of IPsec gateways to support this specification, > > all members MUST be able to tell whether a particular IKE SA is active > > anywhere in the cluster. One way to do it is to synchronize a list of > > active IKE SPIs among all the cluster members. I think this paragraph should perhaps be before the text about section 5.2, as this is more generic. > OK, let's have an extra round before we go to IETF Last Call. If no one > disagrees with Dave's new wording before Tuesday, Feb 15, I will ask the > authors to put it in a new draft. Actually by reading the section 5.2 text, it is does not give any way to actually safely use section 5.2 token generation in load balancing cases. I think people who wanted the section 5.2 text here wanted to actually use it in load balancing cases, and in their setup it was made impossible to forward packets with one load balancing gateways destination address to another gateway, i.e. made it impossible for the attacker to trick gateway sending QCD token for an existing IKE SA. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
<<inline: graycol.gif>>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
