Subject: [eap] Re: limits of protected result indications

From: Bernard Aboba <[email-masked]>
Date: Fri, 6 Feb 2004 13:54:43 -0800 (PST)

>Lets assume that we are at a point where a key has
>been generated and both sides have exchanged protected
>success indications. And we are at the last message pair.
>Now, lets assume the response (and its retransmissions)
>get lost.

EAP Responses are not retransmitted.  If a Response is lost, then the
authenticator will retransmit the EAP-Request.

>The peer has received and sent all messages
>of the protocol and is expecting Success. The server
>on the other hand is missing the last message. Eventually
>it will give up and is forced to disconnect and not
>grant access.

Assuming that the authenticator retransmits the EAP-Request but does not
receive a Response, yes it will eventually give up.  The peer is
satisfied, so it will grant access.  This is a situation where it is
necessary for a lower layer indication to be sent by the authenticator to
the peer. But if the EAP-Request didn't get through, probably the lower
indication won't either.  As Marshall Rose once said "what you need isn't
a different transport -- what you need is more voltage!"

>In a variation of this scenario there is an attacker
>who creates this situation by blocking the last response.
>The result is DoS where the peer ends up in a lengthy
>timeout while the server performs a disconnect.

It's only a lengthy timeout if the authenticator doesn't send a lower
layer indication.  In 802.11, an authenticator responds to data sent by
the peer in state 1 with a DeAuthenticate and in state 2 with
Disassociate.  The problem of state synchronization can occur for other
reasons, so it's something that other link layers (e.g. PPP LCP-Terminate)
have to handle as well.

>Conclusion? As Hannes pointed out also, protected result
>indications can never provide complete assurance that the
>parties are in sync.

I agree with this.  Lower layer indications play an important role.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap