Subject: [Hipsec] DH keymaterial regeneration during base exchange

From: [email-masked] (Miika Komu)
Date: Fri Jan 23 09:58:00 2004

Kristian and me noted an implementation (?) problem that occurs when DH
keymaterial is regenerated during a base exchange. The use case is listed
below in sequential order. We assume that there is only one DH-key on the
host (per group) in the use case, but the problem probably occurs also
when there are multiple DH-keys on the host. Please see the boundary
conditions after the use case before answering.

1 initiator sends an I1 to responder and goes to I1-SENT
2 responder receives the I1 and sends an R1 with DIFFIE_HELLMAN=DHa
  and stays in state UNASSOCIATED
3 responder decides to regenerate new Diffie-Hellman keymaterial DHb that
  overwrites the old DHa completely
4 initiator receives the R1
5 initiator sends an I2 using DHa keymaterial and goes to I2-sent
6 responder receives the I2 in UNASSOCIATED state with an invalid
  ENCRYPTED param (DHa was used to produce it, not DHb), drops it and
  stays in UNASSOCIATED state
7 initiator timeouts in I2-sent, resends the I2 using DHa
  keymaterial
8 responder drops the I2 again (because DHa was used instead of DHb),
  initiator resends, ...
9 initiator reaches I2_RETRIES_MAX and goes to E-FAILED

Some boundary conditions to keep in mind:
- The responder has a state only after it has received a sound I2.
- Just having multiple DH-keys does not really solve the problem.
  - Consider when you can deallocate a specific DH-key.
    - Counter/lock solution: don't deallocate the DH-key until use count is
      zero. What if the initiator never responds?
- DH-keys are tied to the pregenerated R1s.

Solution 1: Cache the DHa until it expires.
- If DHb did not do the trick on the responder, fall back to using the
  cached DHa if DHa has not expired (and deallocated).
- The probability of fall backing to the cached DHa is quite minimal,
  so it is difficult to use for DoS.

Solution 2: modify the state machine
- In UNASSOCIATED, the responder receives an I2 and encryption fails.
  Resend R1 (with DHb) and don't change state.
- In I2_SENT, the initiator receives R1, processes it, resends I2 and
  stays in I2_SENT.

These were just some coarse grained ideas, we haven't had time to think
about this in more depth yet. Has anyone solved this problem already?
Any ideas?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/