Opened 12 years ago

Closed 11 years ago

#202 closed defect (fixed)

Token makers generating the same tokens without synchronized DB

Reported by: yoav.nir@… Owned by: fd@…
Priority: normal Milestone:
Component: failure-detection Severity: -
Keywords: Cc:


Section 10.4 of the draft has a use-case where a cluster of gateways share the same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases, so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a member that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and that predicting or prescribing load balancer behavior in inherently dangerous.

Change History (4)

comment:1 Changed 12 years ago by yoav.nir@…

  • Owner changed from paul.hoffman@… to fd@…

comment:2 Changed 12 years ago by yoav.nir@…

  • Component changed from draft-ietf-ipsecme-ikev2bis to failure-detection

comment:3 Changed 12 years ago by fd@…

  • Status changed from new to assigned

The exact claim is made of two parts

1- that the shared key token generation is dangerous when used in conjunction with Load Balancer.

2- that the cure is to share the IKE SA DB across all the devices in the cluster

Statement 1 (problem description) is practical but technically incomplete/inaccurate. The problem with address-less token generation happens whenever the following conditions are met:

  • the devices in the cluster use the same QCD temporal key
  • the devices in the cluster can be reached independently by an attacker (e.g. by carefully selecting a source or destination ip, ports, ..)
  • the devices in the cluster can not verify another (still alive) device from the cluster own such an SPI and would respond with undesired INVALID_SPI

The conditions above encompass the intended description (point 1) given by Tero. The problem is thus broader as it applies to HSRP pairs and Anycast clusters.

Thanks to the applicability re-statement, the cure can be different than having to share the IKE SA DB across all members in the cluster. It is sufficient to share a list of SPI's for instance (ignoring the keys, peers etc). So Tero's point 2 can be entirely restated.

There is nevertheless a major security flaw with the address-less token generation.

In general, it is strongly advisable that the QCD token takes in account all the parameters that were used in routing the ESP or IKE packet to the server owning the session. I.e. source and destination ports should be included too by default.

comment:4 Changed 11 years ago by yoav.nir@…

  • Resolution set to fixed
  • Status changed from assigned to closed

Everyone seems OK with the latest iteration, or else too tired to comment.

The important text is there: that an implementation MUST NOT send a valid QCD token in the clear for a valid IKE SA. The draft does not specify what you need to do to make this work in a cluster. Specifically, changes to load balancer behavior are not specified.

Note: See TracTickets for help on using tickets.