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

From: <[email-masked]>
Date: Tue, 16 Dec 2003 11:33:13 +0200

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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Tue, 16 Dec 2003 06:56:47 -0500 (EST)

Hey Pasi,

> This requires some changes to the authenticator state
I was so sure of this too (wrongly)- so I checked and was surprised.

> draft -12 have a new identifier value for EAP Success :-)
In FreeRadius it is as Joe described, at least for TLS. They have a
pretty generic method for sending success though so I assume it's the
same for other methods there. I haven't tested anything else.

Regards,
nick

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 16 Dec 2003 08:57:31 -0800

> draft -12 have a new identifier value for EAP Success :-)

EAP implementation in Open Diameter actually does this, because it is
what the specification says.  On the other hand, its peer
implementation does not check whether the Identifier field in the
received Success message matches the one contained in the latest
Response message, because the specification does not exactly specify
what to do when the mismatch is found.

Yoshihiro Ohba

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 16 Dec 2003 09:52:58 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 1:33 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine
> 
> 
> Hi Joe!
> 
> 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 
[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. 

> > Responses.  The Identifier field MUST match the Identifier field of 
> > the Response packet that it is sent in response to."
> 

[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.