eap Mailing List: Re: Proposed Resolution to Issue 243: State Synchronization

[Bernard Aboba (aboba]

To take a concrete example:

Peer           Attacker            Server

    EAP dialog (e.g. EAP-PSK)
<------------------------------------>

Protected result indication (e.g. Done success delivered by the server
to the peer)
<-------------------------------------

Protected result indication (e.g. Done success delivered by the server
to the peer) intercepted by the attacker
-------------->X

EAP-Success
<--------------

[BA] So the attacker forges an EAP Success?

Protected result indication (e.g. Done
success delivered by the server
to the peer) retransmitted by the server
<-------------------------------------

[BA] Yes, in this example the attacker causes the
peer and server to be de-synchronized.  The peer
thinks it has succeeded -- and the server
will eventually fail.

The EAP peer is not listening any more.

[BA]  The problem isn't that the EAP peer isn't listening --
it is that it is now in a state where it will discard the
retransmitted protected result indication.

I guess my temporary proposed resolution would
be to explicitly give an example like the one
I have given and allude to the distributed
consensus to say that it is *not* what is meant.

[BA] EAP methods are not negotiating ciphersuites
or parameters by which subsequent data may be carried.
Therefore the "state synchronization" is really
about the internal state of the EAP method.
The reason we should care about this is that if
the method is successful, the EAP server and/or peer may
leave behind internal state that may be reused for things
like fast resume.  So that is I think what is being
referred to here -- ensuring the consistency of the
cached state.

For example, in the above situation, the peer may have
created a session cache entry which it may try to
reuse in a subsequent authentication.  The "session
resume" will fail because the EAP server did not
consider the initial conversation a success and did
not create a session cache entry.  So the synchronization
may take more than one round.

[FB] I don't have text.

This document has already been approved by vote of 802.11
with the existing text.  Every technical change results
in a 1+ month delay which in turn causes delays in other
documents.  We've been through this back and forth for
3 round-trips now -- and unless I see a consensus for
changing the existing text, and convergence on what the
replacement text is, then we are going to go with
what we have.