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

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 
> Sent: Tuesday, December 16, 2003 1:33 AM
> To: jsalowey [at] cisco.com; eap [at] frascone.com
> Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine
> 
> 
> 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...?
> 
[Joe] Hmmm... I have the suspicion that you are right.  I'll have a look
though, I feel that there should be a way to simplify it. 

> <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 :-)
> 

[Joe] Yes I remember seeing that in the test vectors but forgot to
comment on it.  Most of the implementations I have worked with use the
same ID for the EAP-Success.  



> Best regards,
> Pasi
>