Subject: [eap] New Supplicant Back-end Machine proposal (fwd)

From: [email-masked] (Bernard Aboba)
Date: Thu, 9 Jan 2003 13:50:33 -0800 (PST)

This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [email-masked] for more info.

------_=_NextPart_000_01C2B82F.021A0AB0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <[email-masked]>

---------- Forwarded message ----------
Date: Thu, 9 Jan 2003 14:32:35 -0800
From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,
     "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>,
     Robert Moskowitz <[email-masked]>, James Burns <[email-masked]>
Cc: 'Tony Jeffree' <[email-masked]>, 'Bernard Aboba' <[email-masked]>,
     [email-masked]
Subject: New Supplicant Back-end Machine proposal

Not the greatest write-up, but hopefully somewhat helpful....

802.1X Supplicant to EAP Switch Interface
-----------------------------------------

Attached is a new proposed 802.1X supplicant backend that is intended to
interface with the EAP Peer switch layer.  This machine is intended to
replace the current supplicant backend machine in 802.1aa/D4.  The following
are notes about how this works:

Goals
-----

1. To provide a packet handshake interface to the EAP layer that supports
the actions of the EAP layer
2. To remove interpretation and action upon EAP packets within 802.1X (for
the most part)
3. To do so without completely re-writing the rest of the supplicant
machines
4. To give the EAP layer complete decision power over the authentication
state of the supplicant

Key Observations
----------------

1. The eapSuccess and eapFailure variables have been completely removed from
the supplicant.  These variables were set true when an EAP-Success or
EAP-Failure message were received.  The EAP layer is now responsible for
interpreting and acting upon EAP-Success and EAP-Failure messages.

2. Each EAP packet received by the supplicant is handed to the EAP layer
one-by-one.  The EAP layer handshakes each packet using a set of variables.
The EAP layer will either respond to the supplicant backend with an
indication to send an EAP-response packet, or an indication that no response
will be coming.  In the later case, the EAP layer is either silently
discarding the EAP frame or a response frame is not necessary.

3. The EAP layer determines the if the sequence succeeds or fails and
informs the supplicant machines by setting the global variables suppSuccess
or suppFail.

Other Ramifications
-------------------

1. The supplicant txKey machine must be slightly modified since the
eapSuccess variable has been removed.  The eapSuccess variable should simply
be replaced by the suppSuccess variable.

2. The supplicant front-end machine must set suppStart when either an
EAP-Request, EAP-Success or EAP-Failure packet is received.  The suppStart
variable is how the supplicant back-end machine is started.  It currently
only sets the suppStart variable when the initial EAP-Request is received
from the authenticator.  Basically, the suppStart variable should be set
when any EAP message is received.

New Variables and handshakes
----------------------------

suppRsp - a global variable set TRUE by the EAP layer when it is done
processing a received EAP frame and intends to send an EAP-response frame
back to the authenticator.  The variable is set FALSE by the supplicant
back-end after the response has been sent.

suppNoRsp - a global variable set TRUE by the EAP layer when it is done
process a received EAP frame but does not intend to send an EAP-response
back.  The variable is set FALSE by the supplicant back-end.

eapRcvd - a variable that indicates an EAP packet has been received.  In
particular the supplicant should only really care about EAP-Request,
EAP-Success and EAP-Failure messages.  This variable replaces reqRcvd,
eapSuccess and eapFail in the old machine.

Old variables with new semantics or owners
------------------------------------------

suppSuccess - the global variable that the EAP layer sets to indicate it is
'done' and the result is a successful authentication.  The supplicant
front-end machine will transition into the authenticated state when this is
set (and of course the port is valid).

suppFail - the global variable that the EAP layer sets to indicate it is
'done' and the result was a faile authentication.  This failure could be as
a result of many things, but the supplicant backend machine doesn't really
care.

How things work
---------------

1. The supplicant front-end machine is virtually untouched.  It works as it
does today with the exception of setting suppStart when either an
EAP-request, EAP-Success or EAP-Failure message are received.  Basically, it
initializes, send EAPOL-Start messages and waits for an initial message from
the authenticator.  When the initial message from the authenticator is
received, the variable eapRcvd is set TRUE and suppStart is set TRUE and the
back-end machine wakes up.

2. The backend machine has a frame available for the EAP layer anytime
eapRcvd is set TRUE.  It waits for an acknowledgement that the EAP layer is
done working with the frame by looking for either suppRsp or suppNoRsp going
TRUE.

3. If suppRsp goes TRUE, the supplicant sends an EAP-Response frame,
restarts its timeout and waits for the next frame from the authenticator

4. If suppNoRsp goes TRUE, the supplicant simply restarts it timeout and
waits for the next frame from the authenticator

5. if suppSuccess or suppFail go TRUE, the supplicant back-end is basically
done

6. if the timeout pops, we haven't received the next EAP frame from the
authenticator while in the authentication process, so we basically give-up
and start over by sending EAPOL-Start frames.

Paul

------_=_NextPart_000_01C2B82F.021A0AB0
Content-Type: APPLICATION/OCTET-STREAM; NAME="newSupplicantBackend.pdf"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="newSupplicantBackend.pdf"

------_=_NextPart_000_01C2B82F.021A0AB0--