Subject: [eap] design-paper : policy functions and method selection

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Mar 2003 22:27:18 -0500

The state machine presented by Nick Petroni and I included a set of 
"policy" functions which control how what the peer and authenticator/EAP 
server interact to select methods and determine if a dialog is successful. 
The following is a description of some possible "policy" functions and how 
the interoperate.

Please comment or question.  -- John

Controlling EAP dialogs.

The following describes possible scenarios for Authenticator (EAP server) 
and Peer.
In the state machine these are driven by "Policy" functions in the Peer and 
Authenticator/EAP server.

The intent of this is to show how different implementations of these 
functions on Peer and Authenticator/EAP server can interoperate.  It also 
shows how the state machine is affected by this "policy" only at these 
function interfaces.

----------

Scenario 1 - single EAP method(m1)+ Identity  on Peer and EAP server

Peer
Accepts request for Identity and for m1.  It NAKS requests for any other 
methods.
Does not require any authentication, but if any method fails in the Peer it 
will go to a local failure state and refuse to bring up the link.

In this scenario the peer state machine "policy" functions will do the 
following

Policy.allow checks the requested method against Identity and m1.  If it is 
either, then the result is true, else false.
Policy.isSatisfied is true if no method has failed, false if any method 
fails locally.

EAP server
Drives EAP dialog.  Initiates Identity and then m1.  Both must succeed for 

the dialog to succeed.
The state machine "policy" functions for the authenticator will do the 
following

Policy.getNextMetod returns Identity on first call, m1 on second call, NONE 
on third and subsequent calls.
Policy.isSatisfied returns false until m1 succeeds.

In this scenario a successful dialog will do
1. Identity
2. m1 - succeed
3. EAP Success
------------------

Scenario 2 - same as Scenario 1, except the EAP server has an additional 
method (m2) which it proposes before m1.  If m2 is accepted it does not do 
m1.  One method must be done and succeed for the dialog to succeed.

Peer - same as Scenario 1

EAP server
Drives EAP dialog.  Initiates Identity and then m2. If m2 is NAK'd then it 
does m1.  Identity and either m1 or m2  must succeed for the dialog to 
succeed.
The state machine "policy" functions for the authenticator will do the 
following

Policy.getNextMetod returns Identity on first call, m2 on second call.  If 
m2 is NAK'd it returns m1 on the third call, else None.  NONE on fourth and 
subsequent calls.
Policy.isSatisfied returns false until m1 or m2 succeeds.

In this scenario a successful dialog will
1. Identity
2. m2 - NAK
3. m1 - succeed
4.EAP Success

-------

Scenario 3 - Same as Scenario 2 except Peer requires m1 to succeed on the 
peer to be successful

Peer
Accepts request for Identity and for m1.  It NAKS requests for any other 
methods.
Requires m1 to succeed to bring up its end of the link

In this scenario the peer state machine "policy" functions will do the 
following

Policy.allow checks the requested method against Identity and m1.  If it is 
either, then the result is true, else false.
Policy.isSatisfied is false until m1 succeeds

In this scenario a successful dialog is the same as in scenario 2.  However
the peer now has a policy requiring a particular method (m1) to succeed 
before bringing up the link.  This is a "simple" policy for a peer that 
requires a "mutual authentication" method.

----------

Scenario 4 - EAP server has a required and two optional methods in addition 
to the Identity.  (Optional methods might be vendor specific 
configuration/provisioning support methods).  Required method is m1. 
Optional methods are opt1 and opt2.

Peer acts as in Scenario 3.

EAP server
Drives EAP dialog.  Initiates Identity and then m1.  Both must succeed for 

the dialog to succeed.
The state machine "policy" functions for the authenticator will do the 
following

Policy.getNextMetod returns Identity on first call, m1 on second call, opt1 
on third, opt2 on fourth, None on fifth and subsequent calls.
Policy.isSatisfied returns false until m1 succeeds and both opt1 and opt2 
are proposed and do not fail(could be NAK'd).

In this scenario a successful dialog is

1. Identity
2. m1 -succeeds
3. opt1 - NAK
4. opt2 - NAK
5. EAP Success

----------

More scenarios are possible, but the above are a beginning to show how 
different policies on authenticator and peer will work together.