eap Mailing List: RE: [Issue 203] Comments on EAP-Peer state machine

[Pasi.Eronen (Pasi.Eronen]

Hi Joe!

And thanks for your comments. See my replies inline.

> > - Item 3 is a bit more complicated. 
> > 
> >   Integrity check is currently a separate procedure to show that 
> >   when a packet is silently discarded, methodState and decision 
> >   (and other state) remain unchanged. You're right in that a 
> >   method can produce an error for invalid packets instead...
> >   Maybe it would be better if we rename m.integrityCheck() to 
> >   m.check() and "intCheck" to "discard"? (and change transition 
> >   "!intCheck" to "discard")
> >   
> >   Combining methodState and decision to a single variable is 
> >   certainly possible, but four different states (plus one 
> >   indication for IGNORE) are not enough: there are seven different
> >   combinations. The reason we originally split it was to make the 
> >   transitions to SUCCESS and FAILURE states a bit more compact 
> >   (they're quite complex anyway, but become totally unreadable 
> >   if the variables are combined...). 
> > 
> 
> [Joe] I think integrity check is internal to the mechanism and 
> should not be exposed outside the mechanism. I think there should 
> be a single call into the method that results in one of n possible 
> results.  In looking at the state machine I counted 5: IGNORE, 
> CONTINUE, COND_SUCCESS, SUCCESS, FAILURE.  What are the additional 
> values?

Of the 3*3 combinations for (methodState,decision), the only ones 
that are not allowed are (CONT,COND_SUCC) and (CONT,UNCOND_SUCC).
So we have seven combinations left. No two of them result in exactly 
same transitions in all circumstances (I actually checked this :-), 
so they can't be combined without changing the behavior of the 
state machine.

We could, of course, change the behavior as well if you have some 
suggestions on what to change...?

<snip>

> > - Item 5: it might check (reqId != lastReqId) (not "=="), 
> >   but I don't think this is necessary, since Success/Failure 
> >   are never retransmitted.
> 
> [Joe] I've lost the context to this, but I thought that 
> EAP-Success and EAP-Failure had the same ID as the previous 
> request and response.  From 2284bis Section 4.2:
> 
> "Identifier
> 
> The Identifier field is one octet and aids in matching replies to
> Responses.  The Identifier field MUST match the Identifier field
> of the Response packet that it is sent in response to."

Hmm, you're right... (I had thought that each EAP packet
sent by the authenticator gets a new identifier value).
This requires some changes to the authenticator state 
machine as well.

(BTW, do you have any idea whether current implementations 
actually do this? At least the EAP-SIM test vectors in 
draft -12 have a new identifier value for EAP Success :-)

Best regards,
Pasi