Subject: [eap] EAP Design Team -- This week's position papers

From: [email-masked] (John Vollbrecht)
Date: Wed, 16 Oct 2002 06:43:58 -0400

I will try to be on the call today, but I may not make it due to a
conflicting obligation.

My comment on the state machine issues is that I think there is some
confusion (at least for me) in what the model for the interactions is. 
The current state machine seems to tie together what has been called the
"mux" or "EAP-switch" process and the EAP-Methods process.  

Clearly separating them seems to me to make the description simpler to
understand and possibly to implement.  Making this distinction means
that at each end - Peer and Authenticator - there are two processes. 
The EAP-switch process and the EAP-Method.  

The EAP-switch processes at each end communicate to select a (sequence
of) method(s) and to decide when the process is done.  The EAP-switch
sends Success and Failure messages.

The EAP methods at each end communicate with each other.  They also
communicate with the EAP-switch at their end.  The methods may have
their own state machine independent of the EAP-switch, which also has a
state machine.

It seems to me to be mostly the EAP-switch state machine we are dealing
with.  I think the EAP-switch state machine should have events that are
messages from the remote EAP-switch AND events that are signals from the
local EAP methods.

This probably means that a model of an EAP-switch / EAP-method interface
needs to be proposed.  A high level model.  The interface should include
signals and variable (such as identity) passing.  If people think this
would be helpful I can try to put together a straw man proposal for such
an interface by next week.

-- John