Subject: [HOKEY] Potential Problem with Sequence Number Management in EAP Re-Authentication Protocol <draft-ietf-hokey-erx-08>

From: "Katrin Höper" <[email-masked]>
Date: Wed, 12 Dec 2007 16:40:09 -0500

Lakshminath, Vidya and others,

There might be a problem with the proposed usage of sequence numbers for
re-authentication, if multiple protocol sessions are initiated *
simultaneously* by the same peer with several authenticators in range.

Set Up:

   - Peer P successfully completed a full EAP authentication with his
   home server AS.
   - The resulting re-authentication integrity key rIK is stored on P and
   AS.
   - The server stores (rIKname, rIK, SEQ_rIK=0)

 Assumptions:

   - Peer P is in range of multiple authenticators (say Auth1 and Auth2),
   which are connected to the same authentication server (say AS)
   - P initiates Re-Auth protocol with each authenticator in range
   simultaneously, i.e. P sends a message containing SEQ_1=0 to Auth1 and
   sends out another message containing SEQ_2=1 to Auth 2
*before*receiving response from Auth1.
   - The network delay in network 2 is shorter and thus the message from
   Auth 2 reaches AS first. AS looks up SEQ_rIK and checks whether
   SEQ2=1>=SEQ_rIK=0. The check is successful and AS sets SEQ_rIK=SEQ2=1.
   - Now the message from Auth1 reaches the server. AS checks whether
   SEQ_1=0>=SEQ_rIK=1. This check fails and thus the Re-Auth fails.

Similar problems may exist if a peer initiates several protocol sessions
with the same authenticator due to message loss or time outs.

The described problem is based on the unpredictability of which of the sent
protocol messages will reach the server first and the intolerance of the
protocol to sequence numbers that are slightly out of sync.

If parallel sessions are considered to be in the scope of the proposed
draft, the proposed sequence number management should be modified to prevent
the outlined problems (e.g. by allowing a window of acceptable sequence
numbers). Otherwise, it seems advisable to mention that simultaneous
protocol executions are prohibited. Note that sequential protocol executions
are significantly slower.

Katrin Hoeper
_______________________________________________
HOKEY mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 13 Dec 2007 13:01:36 -0800

Hi Katrin,

You make a good point.  I was working with the assumption that the peer 
runs multiple reauthentications in sequence to avoid such problems.  We 
have not documented that.  We can do so as part of the revision after AD 
review or IETF LC review.  I would not be as concerned about the delays. 
  One could use the optimization techniques you and I discussed in 
Vancouver.

But there is no reason to not use windowing technique you mention, but 
that needs to be mandated to avoid any interoperability issues.  I have 
no objection to either direction.  Any other opinions?

regards,
Lakshminath

On 12/12/2007 1:40 PM, Katrin Höper wrote:
> re-authentication, if multiple protocol sessions are initiated 
> _simultaneously_ by the same peer with several authenticators in range.
> 
>  
> 
> Set Up:
> 
>     * Peer P successfully completed a full EAP authentication with his
>       home server AS.
>     * The resulting re-authentication integrity key rIK is stored on P
>       and AS.
>     * The server stores (rIKname, rIK, SEQ_rIK=0)
> 
>  Assumptions:
> 
>     * Peer P is in range of multiple authenticators (say Auth1 and
>       Auth2), which are connected to the same authentication server (say
>       AS)
>     * P initiates Re-Auth protocol with each authenticator in range
>       simultaneously, i.e. P sends a message containing SEQ_1=0 to Auth1
>       and sends out another message containing SEQ_2=1 to Auth 2
>       _before_ receiving response from Auth1.
>     * The network delay in network 2 is shorter and thus the message
>       from Auth 2 reaches AS first. AS looks up SEQ_rIK and checks
>       whether SEQ2=1>=SEQ_rIK=0. The check is successful and AS sets
>       SEQ_rIK=SEQ2=1.
>     * Now the message from Auth1 reaches the server. AS checks whether
> The described problem is based on the unpredictability of which of the 
> sent protocol messages will reach the server first and the intolerance 
> of the protocol to sequence numbers that are slightly out of sync.
> 
>  
> 
> draft, the proposed sequence number management should be modified to 
> prevent the outlined problems ( e.g. by allowing a window of acceptable 
> sequence numbers). Otherwise, it seems advisable to mention that 
> simultaneous protocol executions are prohibited. Note that sequential 
> protocol executions are significantly slower.
>  
> Katrin Hoeper

---

From: "Katrin Höper" <[email-masked]>
Date: Wed, 19 Dec 2007 11:53:06 -0500

Hello Lakshminath,

thanks for your quick reply.

I agree that documenting your assumption about sequential protocol
executions is important and should be included in the next document version
(when is up to the ADs).

I plan to further investigate the window approach by simulating parallel and
sequential sessions with different window sizes.
 May be the results can then serve as a basis for dicussing whether adding a
window technique is useful and how such schemes could be implemented.

However, due to the upcoming holidays I don't expect any results too
soon. My rough estimate for first results would be the end of January. I
will post them to the list.

Best regards,
Katrin Hoeper

---

From: Charles Clancy <[email-masked]>
Date: Sat, 22 Dec 2007 18:01:05 -0500

I've created issue #38 to track this issue.  Once it's addressed in the 
document, let me know, and I'll close it.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Katrin Höper wrote:
> executions is important and should be included in the next document 
> version (when is up to the ADs).
>  
> I plan to further investigate the window approach by simulating parallel 
> and sequential sessions with different window sizes.
> May be the results can then serve as a basis for dicussing whether 
> adding a window technique is useful and how such schemes could be 
> implemented.
>  
> On Dec 13, 2007 4:01 PM, Lakshminath Dondeti <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Katrin,
> 
> ------------------------------------------------------------------------
>

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 22 Dec 2007 15:52:57 -0800

…

[gwz]

 I think that, while the results of your simulation work will undoubtedly
useful, there is no real need to wait for them to add the windowing scheme
to the draft.

[/gwz]

…

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 22 Dec 2007 18:42:55 -0800

Hi Glen, Katrin,

I am ok with adding the windowing adding as I noted earlier.  Let me put 
the question to the group in a different way.

Any objections to adding the windowing technique?  I would add that it 
is merely a recommendation on server behavior.

regards,
Lakshminath

On 12/22/2007 3:52 PM, Glen Zorn wrote:
> ...
> */[gwz]/*
> */ I think that, while the results of your simulation work will 
> undoubtedly useful, there is no real need to wait for them to add the 
> windowing scheme to the draft./*
> 
> */[/gwz]/*
> 
> ...
> 
>  
>