Subject: [Hipsec] bug in E3 in the state machine?

From: [email-masked] (Miika Komu)
Date: Thu Nov 6 10:50:02 2003

draft-08, section 5.4.2_

   +---------+
   |    E3   | HIP SA established
   +---------+
   ..
   Receive R1, process with SA and Birthday check
        if successful, send I2, prepare to drop old SA and cycle at E3
   ..
   Receive R2, drop and stay at E3

Receive R1, send I2 but drop the incoming R2? Is there are bug here or did
I misunderstand something?

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

---

From: [email-masked] (Pekka Nikander)
Date: Fri Nov 7 02:55:02 2003

> draft-08, section 5.4.2_

I think this is my mistake between -07 and -08.

If I remember correctly, earlier the rule was to go to E2 upon
receiving an R1.  However, if an attacker can force the peer
to increment the birthday counter (that seems doable), it can
then trigger a suitable R1 and replay it to the target node,
causing the target node to unnecessarily to drop the IPsec SAs
and go to E2.  That would be bad.

Hence, I changed the rule to "prepare to drop" the old SAs instead
of dropping them, and cycling back to E3.  Apparently that wasn't
quite enough.

I see two basic choices in dealing with this:

   1. Create a new state (E5), as somebody suggested.

   2. Change the rule on receiving R2 to read something like

      "Receive R2, check if a corresponding R1 has been
       recently received, ....

I think a new state would probably be better.

One more thing.  I don't know if it is good to name the
substates of E3 as E4, E5, ... as we do now.  Maybe it would
be better to have E3 (as now), rename E4 as E3.1, and make
the new state E3.2.  In that way the new states would be
understood to be substates of E3, making the spec perhaps
easier to understand.

And yes, somebody has to work out the interactions between
E4/E3.1 and E5/E3.2.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Nov 7 03:24:00 2003

On Friday 07 November 2003 09:25, Pekka Nikander wrote:
> > Receive R1, send I2 but drop the incoming R2? Is there are bug here or
> > did I misunderstand something?
>

I concur cuz an implementation isn't supposed to keep track of received R1s 
(2), as opposed to (1), where receiving an R1 cause the state machine to 
transition to E3.resync (or E5), so that the subsequent R2 can be accepted 
for some duration (I guess we needs to timeout and revert to E3 after some 
time waiting for an R2).

> understood to be substates of E3, making the spec perhaps

I agree too. What about E3, E3.rekey (E4), and E3.resync (E5) ?

> And yes, somebody has to work out the interactions between

I'll try to take a look at that.

Thanks,

--julien

---

From: [email-masked] (Robert Moskowitz)
Date: Tue Nov 11 11:41:01 2003

This state machine first appeared in 05.txt (replacing the harder to follow 
state machine in 04).  It had the drop R2 in E3 back then.

An R2 while in E3 can be the result of:

A replay attack.  Drop it.
A retransmission for some stupid reason.  It was a stupid desision by 
something and Drop it.

This is in there for state machine completeness.  Each state MUST have a 
response for ANY possible HIP dataframe.

As a result of this review, I noticed that in 5.4.3, state E3, does not 
list R2 for staying in E3.  R2 should be added to the list of datagrams on 
that loop link.

Thank you for this opportunity to go back and look at my effort for this 
state machine,  in the next six months I have committed to redesigning the 
state machines in IEEE 802.1X so that there is only one machine for both 
parties like HIP has.  Not like the current Supplicant/Authenticator 
machines  :)

At 07:20 AM 11/6/2003, Miika Komu wrote:
>_______________________________________________
>Hipsec mailing list
>[email-masked]
>http://honor.trusecure.com/mailman/listinfo/hipsec