Subject: [eap] Issue 229: EAP Peer SM Review

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Mar 2004 19:43:00 -0800 (PST)

Issue 229: EAP Peer SM Review
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 2/28/2004
Reference:
Document: EAP-SM-02
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Overall:

Peer and authenticator are inconsistently capitalized. Suggest
using lower case for both, as is done in RFC 2284bis.

Page 5

"all other EAP packets are delivered to the Peer state machine."

This should instead say "EAP packets with Code set to
Request, Success or Failure are delivered to the peer state machine."

Page 6, Section 3.1

"connected,mutually" -> "connected, mutually"

"conditions.A variable" -> "conditions. A variable"

Page 7, Section 3.1

"such as that of the Method." -> "such as that of the method."

Page 9

In Figure 3, the variable lastId is not initialized to NONE in the
INITIALIZE state.

I am not sure that (altAccept && decision != FAIL) is a condition that
should lead to the SUCCESS state. Why is this not
decision == UNCOND_SUCC as with a timeout?

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

---

From: Nick Petroni <[email-masked]>
Date: Thu, 4 Mar 2004 00:55:18 -0500 (EST)

I have put up a -03a to address some of these. comments inline.

http://www.cs.umd.edu/~npetroni/EAP/

> using lower case for both, as is done in RFC 2284bis.
[np] Fixed I think. let me know if I missed any.

> Request, Success or Failure are delivered to the peer state machine."
[np] fixed.

> "conditions.A variable" -> "conditions. A variable"
[np] aaah. gotta love acroread in Linux. besides its propensity to crash
when searching it also copies horribly at the end of the line. nice catch.

> "such as that of the Method." -> "such as that of the method."
[np] fixed.

> decision == UNCOND_SUCC as with a timeout?
[np] It seems that altAccept is an alternative to rxSuccess so it should
be equivalent to that input I think. The current diagram shows
rxSuccess && (reqId == lastId) && (decision != FAIL). So, if you change
one, you should have to change both right? I think it's right as is, but
I could be convinced otherwise.

I think the idea behind decision is as follows:

UNCOND_SUCC  peer already knows auth's decision is yes and wants to accept.
             Since it knows the decision, it can assume the success
             packet was lost in transit on a timeout.

COND_SUCC   peer wants to accept, but doesn't yet know what the auth
             has decided. It therefore needs some indication of success to
             go to the SUCCESS state.

FAIL         peer or auth is not happy, either way don't go to success

I think the point is that timeout requires you to KNOW you have succeeded
(decision=UNCOND_SUCC) whereas success/altAccept *is* the indication you
are waiting for when decision=COND_SUCC. So, those events can transition
to SUCCESS when decision is COND_SUCC as well. Does that make sense?

regards,
nick