Subject: [eap] [Issue] Corner case in 802.1X/EAP State Machines

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 May 2004 08:22:14 -0700 (PDT)

Recent interoperabilty tests have discovered a corner case in the
802.1X/EAP State Machines where it is not entirely clear what the correct
behavior is:

  Supplicant                               Authenticator                          AAA Server
            ------- EAPOL-Start ----------->
            <----- ID Req(1) -----------------
            ------- EAP Response(1)---------------------------------------------------->
            <----- EAP Request(2) -------------------------------------------------------
            ------- EAPOL-Start ----------->

What is the correct behavior for the Authenticator?

1. Retransmit the EAP-Request (ID=2)?
2. Abort the EAP authentication and send another EAP-Request (ID=3)?

Since there is an EAP-Request outstanding, the EAP state machine appears
to indicate that the correct response is to retransmit (option 1).
However, the IEEE 802.1X-REV state machine appears to indicate that the
correct response is to abort authentication.

Note that the AAA server has sent an EAP-Request with ID=2 so that it is
expecting an EAP-Response with ID=2, which is not what it would get if the
Authenticator takes Action #2.

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

---

From: Jim Burns <[email-masked]>
Date: Fri, 07 May 2004 12:13:39 -0400

Hi Bernard,
    My hand trace of the state machine indicates that they define the 
result to be #2.
                " 2. Abort the EAP authentication and send another 
EAP-Request (ID=3)"
    This occurs because an EAPOL-START from the .1X supplicant means to 
(re)start the .1X process.

Details of hand trace follow:
----------------
Starting states:
    .1X authenticator front end machine is in the AUTHENTICATING state
    .1X authenticator back end machine is in the REQUEST state
    EAP authenticator machine is in the IDLE state
------------------
Hand trace following the event:  EAPOL-Start arrives.
         .1X authenticator front end machine transitions to the ABORTING 
state, setting authAbort to TRUE
         .1X authenticator back end machine transitions to the INTIALIZE 
state (due to authAbort) and sets authAbort to FALSE
         .1X authenticator front end machine transitions to the RESTART 
state and sets eapRestart to TRUE
         EAP authenticator machine transitions to the INITIALIZE state 
restarting the EAP authenticator machine that will cause a NEW beginning 
EAP request (often, but not always a request id) to be sent from the 
authenticator with a new EAP ID.

Hope this helps,
Jim B.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 May 2004 09:29:15 -0700 (PDT)

Thanks.

The question is whether this behavior is consistent with RFC 3748.  For
example, Section 4.1 states:

"Additional Request packets MUST be sent until a valid Response packet is
received, or an optional retry counter expires."

---

From: John Vollbrecht <[email-masked]>
Date: Fri, 07 May 2004 14:40:26 -0400

> received, or an optional retry counter expires."
It seems in this case that the lower layer terminates the initial session 
and causes a restart.  If EAP knows that the lower layer is terminated then 
I am not sure why it would continue to resend.

Perhaps a additional clause in the 3748 document saying

" --- until a vialid Respons packet is received, an optional retry counter 
expires, or a termination of the sequence is received from the lower layer."

> > > 802.1X/EAP State Machines where it is not entirely clear what the
> > > correct behavior is:
> > >
> > >  Supplicant                               Authenticator
> > >  AAA Server ------- EAPOL-Start ----------->
> > >            ------- EAP
> > >            Response(1)-----------------------------------------------
> > >            -----> <----- EAP Request(2)
> > >            -------------------------------------------------------
> > > Since there is an EAP-Request outstanding, the EAP state machine
> > > appears to indicate that the correct response is to retransmit
> > > (option 1). However, the IEEE 802.1X-REV state machine appears to
> > > indicate that the correct response is to abort authentication.
> > >
> > > Note that the AAA server has sent an EAP-Request with ID=2 so that it
> > > is expecting an EAP-Response with ID=2, which is not what it would
> > > get if the Authenticator takes Action #2.
> > >

---

From: Jari Arkko <[email-masked]>
Date: Fri, 07 May 2004 22:28:45 +0300

> to indicate that the correct response is to retransmit (option 1).

You could also look at this as EAPOL-Start starting a completely
new EAP run. The EAP state machine allows sending a new request,
if (a) portEnabled is temporarily set to false, or (b) we are
talking about another instance of the state machine.

But I don't know 802.1X well enough to say if its doing
(a) or (b).

> Authenticator takes Action #2.

Right. This implies that if the EAP authentication is aborted, the
AAA transaction has to be abandoned as well, and a new one started.

--Jari

---

From: Paul Funk <[email-masked]>
Date: Sun, 09 May 2004 03:54:46 -0400

Bernard,

The new 802.1X Authenticator state machine is just plain wrong.

The problem is that upon association both sides start sending. The
authenticator sends an EAP-Request/Identity while the supplicant
sends an EAPOL-Start.

The old 802.1X state machines had it right. If the authenticator
receives an EAPOL-Start after sending its EAP-Request/Identity,
it simply sends another Request-Identity with the same ID. This
has the benign effect of causing two EAP-Response/Identity
messages to be sent by the supplicant. The second is simply
ignored by the authenticator, and there is not an issue of two
authentication sessions being created.

The new 802.1X state machines move the Identity logic out of
the PAE state machines into the Backend state machines. An
Identity message in either direction is no longer anything special,
and cannot be distinguished from other EAP messages. Now the
authenticator PAE state machine is at a loss for how to control
the backend so it doesn't think that a whole new authentication is
required.

Note that there are existing APs that don't implement the old (but
correct) state machine logic, and they cause all kinds of havoc
with RADIUS servers. Some start an authentication session with
the RADIUS server, then abandon it and start a new one. Some
even send the State attribute from the first authentication in the
new authentication. So in a sense this is not a new problem.

There is no reason to abort an authentication because an EAPOL-Start
has arrived, if the only packet sent by the AP is an EAP-Request/
Identity. This is akin to two peers both initiating a TCP session with
the other - you're supposed to end up with just one session.

However, it is necessary to abort the authentication upon EAPOL-Start
if it has gone further than EAP-Request/Identity having been sent. This
does indicate that the supplicant wishes to abort that EAP session. It is
also necessary for receipt by the AP of an EAPOL-Start to cause
resend of EAP-Request/Identity, since it cannot be determined whether
the original EAP-Request/Identity has been lost. It's a good idea, I think,
for the resend of the EAP-Request/Identity to use the same ID; this
guarantees that both sides will treat it as a duplicate packet in the same
authentication session.

Since in the new 802.1X state machines, EAP-Request/Identity is no
longer a "canned" packet, one must conclude that this was done to
allow the AP to send an EAP-Start to the RADIUS server, in order to
allow the RADIUS server to issue the EAP-Request/Identity. I'm not
sure why that would be useful. However, if that is the intent, the only
way to fix the state machine would be for the authenticator PAE to
cache the initial EAP-Request/Identity and resend it if it receives an
EAPOL-Start. This would be done from its CONNECTING state,
not from its AUTHENTICATING state - in AUTHENTICATING, an
EAPOL-Start would abort the authentication and initiate a new one.

Note that there is confusion as to how to transition from CONNECTING
to AUTHENTICATING. The diagram indicates that the transition occurs
when the first request is sent. However, documentation of the
"authEntersAuthenticating" counter indicates that the transition occurs
upon receipt of EAP-Response/Identity. I think the latter makes more
sense, and would enable the type of logic I've suggested.

Paul

At 08:22 AM 5/7/2004 -0700, Bernard Aboba wrote:
> Response(1)---------------------------------------------------->
>             <----- EAP Request(2) 

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 May 2004 08:15:01 -0700 (PDT)

Thanks very much for your detailed response.  I agree that the current
802.1X state machine does not handle "simultaneous initiation" correctly
-- and that this is the root of the issue that we are seeing.

---

From: Jim Burns <[email-masked]>
Date: Mon, 10 May 2004 10:32:46 -0400

Hi folks,
    Just to bring some clarity to the history of why 802.1XRev has 
changed with regard to the initial EAP request handling:

> sure why that would be useful. 

The reason that the 802.1XRev state machines operate without reference 
to 'request id' is because the new RFC 3748 states, in section 2:  
"Typically, the authenticator will send an initial Identity Request; 
however, an initial Identity Request is not required, and MAY be 
bypassed.  For example, the identity may not be required where it is 
determined by the port to which the peer has connected (leased lines, 
dedicated switch or dial-up ports); or where the identity is obtained in 
another fashion (via calling station identity or MAC address, in the 
Name field of the MD5-Challenge Response, etc.)." 

In this case, the 802.1X-2001 standard is broken and would not allow 
this.  In order to allow this as well as the existing request-identity, 
the 802.1XRev was altered to simply transfer EAP requests and responses 
and leave EAP management (and the EAP ID management) to EAP.

> However, if that is the intent, the only

The latter (text related to authEntersAuthenticating) is incorrect text 
and should instead read 'transition occurs upon receipt of response to 
initial request (typically EAP-Response/Identity)'.  In order to 
accomodate 3748, 802.1XRev takes no position on what the initial EAP 
request may be.

I believe the correct fix would be as follows:
The EAP state machine (not the .1X state machine) differentiates between 
its initial EAP request and subsequent requests following receipt of a 
response to its initial request.  If  EAP is in the initial state and 
receives an 'eapRestart' then it ignores it and just resends its initial 
request with the same ID.  In other words, put the resend of the initial 
request that used to reside in the .1X-2001 machine in the EAP machine.

An initial suggestion (I have not fully hand traced this) as to how this 
might be done  would be to modify the EAP Authenticator state machine 
with the following:
1.  add an internal variable:  eapBegun.
2.  Set eapBegun to FALSE in INITIALIZE state.
3.  On the transition from IDLE to RETRANSMIT alter the logic from 
'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && 
(eapRestart )))'
4.  Change unconditional transition into INITIALIZE from 'eapRestart && 
portEnabled' to '(eapRestart && (eapBegun=TRUE)) && portEnabled)'
5.  Set eapBegun to TRUE in RECEIVED state.

I doubt this catches all the nuances, and I am sure the EAP state 
machine folks might do it more elegantly, but I believe that this 
achieves the goal that Paul has discussed.

Hope this helps,
Jim B.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 May 2004 08:29:43 -0700

Hi Jim,

> 'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && 

The eapRestart variable is set to FALSE in INITILIZE state, so I don't
think this logic change does not change the actual behavior.

> achieves the goal that Paul has discussed.

As EAP always assumes that EAP authentication is initiated from EAP
authenticator, I believe it should be the task of an EAP transport
protocol (e.g., IEEE 802.1X) to have its own mechanism to avoid the
race condition in initiaton of an EAP transport session.  As an
example, PANA has its own mechanism to avoid a similar race condition
in initiaton of a PANA session.  Thus, I don't think changing EAP
state machine as suggested is the right solution.

Best regards,

Yoshihiro Ohba

---

From: Nick Petroni <[email-masked]>
Date: Mon, 10 May 2004 23:29:15 -0400 (EDT)

Sorry I am just playing catchup. This is an interesting conversation, but
I am not sure we have yet captured the essence of what is going wrong in
this scenario. First and foremost, I think the 802.1X-REV document is very
clear what it *intends* EAP to do when an EAPOL-Start is received-
everything should be reset. The informative section of that document
reads:

F.3.2 eapRestart
The authenticator state machine sets this signal to indicate to the higher
layer that PAE is restarting. It is expected that the higher layer will
reset its state to remain synchronized with the PAE state machine. The
higher layer must reset this signal to indicate it has completed its own
restart. This signal is required to inform the higher layer of a PAE event
that should cause the termination of in-progress or outstanding
authentications. The higher layer must reset eapSuccess and eapFail after
eapRestart is set true by the PAE layer.

> request that used to reside in the .1X-2001 machine in the EAP machine.

If I understand this correctly, this seems to violate the informative
section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV
machines IMHO. EAPOL-Start means game over as far as I can tell.

The issue from my point of view seems to center around the interaction
between EAP and the backend. One of my primary reasons for this conclusion
is that a standalone authenticator is not likely to have this issue.
eapRestart will be able to reset all state, including policy and the
method, which cannot occur in the backend case. Furthermore, I am not sure
if this really is 802.1X specific. What would happen if there were a
backend authentication server in the PPP case and your phone line
suddenly dropped, followed by the user dialing back in to the same modem?
It seems there must be some way for the authenticator to "reset" the
backend. Perhaps someone can help me distinguish these two scenarios?

It seems to me that either
(1) 802.1X wrongly assumes there is such a thing as "completely reset EAP"
or
(2) EAP is not quite clear how to implement this for passthrough.

#2 seems more likely and my guess is this is RADIUS-EAP specific, but I
could certainly be missing some things in my analysis.

Thanks,
nick

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 May 2004 09:46:48 +0300

> eapRestart is set true by the PAE layer.

The text seems clear. Thanks for highlighting this!

> backend. Perhaps someone can help me distinguish these two scenarios?

I guess one difference in the dial-in case is that this
event would be much less likely than in WLAN, because you
would likely get another port in a large NAS on the second
call. My guess is that we have had this problem all along
in RADIUS/EAP, but have never run into it before now.

> could certainly be missing some things in my analysis.

Your analysis looks valid to me.

--Jari

---

From: Jim Burns <[email-masked]>
Date: Tue, 11 May 2004 10:35:00 -0400

Hi folks,
    I believe there are two cases that could be discussed and I want to 
be sure that we are not talking across cases.  Please note, in the 
following hand traces I am assuming that the EAP identifier generation 
begins with a random number as suggested in 3748.

     1.  Unexpected eapol-start from supplicant during authentication  
(Bernard's original description)
       Supplicant                               Authenticator 
                         AAA Server
                  ------- EAPOL-Start ----------->
                  <----- ID Req(1) -----------------
                  ------- EAP Response(1)--------------------------------->
                  <----- EAP Request(2) 
------------------------------------
                  ------- EAPOL-Start ----------->
                  <----- ID Req(121) -----------------

     2.  simultaneous starts at association time     (Paul Funk's later 
description)
      Supplicant                                   Authenticator         
                     AAA Server
        EAPOL-START------>*<-------ID Req(1)
        ID Req(1)<-----------<*>------>EAPOL-START
        ID Response(1)------->*<-------ID Req(113)
        ID Req(113)<--------<*>------>ID Response(1)->[drop]
        ID Response(113)-------------->ID 
Response(113)------------------->  

The subtle difference is when the eapol-start arrives (as Paul F pointed 
out in his email), and this difference extends to when the state gets 
created on the AAA server.

So in case 1,  the 802.1X-2001 state machine and the 802.1XRev state 
machines react identically (see my previous hand trace).
In case 2, the 802.1X-2001 state machine and 802.1XRev state machines do 
react differently as Paul F. indicates, but I believe the on-wire 
behavior is identical. 

In case 1 (eapol-start-during-authentication) the problem is the following:
   State gets created at the AAA server and after the EAPOL-Start it is 
unclear how that AAA state will get removed unless the new 
authentication  started by the second EAPOL-Start can be differentiated 
from the first authentication.

In case 2 (simultaneous-start) the problem is:
    Nothing, I think, since only one state will get created at the AAA 
server.
    Please note, it is unclear what value the second ID Req will contain 
since I could not find in 3748 where it requires a particular initial 
value.  Hence each new authentication may start with an identifier of 1 
or it may start (as suggested in 3748) with a random number.  In either 
case, only the ID Response that matches the correct identifer will be 
passed along to the AAA server to create state there.    3748 is quite 
clear that the response ID must match the request ID and if not it is 
dropped silently.  If the IDs matched  in the two ID Req (the 
authenticator implementation always starts ids at 1), then 3748 
indicates that the redundant response will be silently dropped.  My 
original suggested solution (several emails ago) that suggested a change 
to the EAP machine was to solve this case, but I now think that there is 
no problem related to this case and my previous email may be ignored.  
(I would add that Nick is 100% correct about the eapAbort signal between 
the lower layer and EAP.  Guess that is why we wrote it down so that we 
would not violate that interface.  Thanks for finding that Nick.)

So, it appears that case 1 is where the problem lies and as Nick P 
points out this appears to be an issue on the back end.  Namely there is 
no signal available in RADIUS that allows the NAS/Authenticator to 
indicate that the AAA server should remove previous state. 

I think that this is an accurate summary so far and I believe that 
Nick's point is accurate to the problem case: case 1.

As Mick has indicated, a simulator would certainly help.  It would be 
quicker and more accurate than the above hand traces.  Anyone know of 
such a simulator?  Or the beginnings of one?

Hope this helps,
Jim B.

Nick Petroni wrote:

>IEEE 802.1 list: see http://www.ieee802.org/1/email-pages/iksbt304.html
>
>  
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 11 May 2004 08:29:10 -0700

>                  ------- EAP Response(1)--------------------------------->

I think there is some problem in case 2 (not exactly the same as case
1, but essentially the same in terms of state synchronization), i.e.,
how the Supplicant can tell whether ID Req(113) is the first EAP
request of the second authentication or the second EAP request of the
first authentication?

It seems to me that it is not a good idea to use EAPOL-Start message
for multiple purposes, i.e., initiating a session and aborting a
session (and then reinitiating a new one).  To accomplish a better
state synchronization, I believe that a different message should be
used for aborting session and that message should be acknowledged
(with some retransmission).

Yoshihiro Ohba