Subject: [eap] Issue 196: Peer SM Issues

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Nov 2003 14:35:50 -0800 (PST)

Issue 196: Peer SM Issues
Submitter name: Ashwin Palekar
Submitter email address: [email-masked]
Date first submitted: Nov 10, 2003
Reference:
Document: SM-01
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:

In Figure 3, it is not clear from the diagrams that SUCCESS and FAILURE
are terminal states; perhaps a function call is necessary to cause
the packet to be sent.

EapTunnelled should probably be a function call rather than
a variable, so that there is no confusion that it is set
when the tunnelled method is selected and applies to either
cleartext or tunnelled packets.

The EapTunnelled variable does not describe the behavior
of current tunneled methods such as PEAP. For example
the state IDENTITY is reached from the RECEIVED state
if (selectedMethod == NONE || EapTunnelled). However
inside PEAP, an Identity can't be sent when a method
has been selected and isn't complete.

Similarly, the transition from RECEIVED to GET_METHOD
seems to occur on EapTunnell == TRUE even if a method
has previously been selected and is in progress. This seems wrong.
Suggest adding a getIdentity() call in the IDENTITY state,
which can take into account the information that the peer
has available, in order to determine the appropriate
identity to put into the EAP-Response/Identity. This
could include, for example, "hints" in the EAP-Request/Identity,
default settings in the peer, etc.
The state machine doesn't appear to suppport sequences
of authentication methods within tunnels.

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

---

From: Nick Petroni <[email-masked]>
Date: Wed, 26 Nov 2003 14:24:15 -0500 (EST)

> In Figure 3, it is not clear from the diagrams that SUCCESS and FAILURE
This is stylistic I think. If there is a special notation for final states
in Figure 3, there should be in all of them. I am open to other
discussion, but I think the text descibing them as final is sufficient.
Other votes?

> are terminal states; perhaps a function call is necessary to cause
There are no packets to send- the Peer does not respond to success or
failure.

> default settings in the peer, etc.
I think this is abstracted away in buildIdentity(). We could add
information about these considerations in the function definition if the
group thinks it is necessary.

The remainder of this issue seems to be about tunnels, so I propose to
reject the issue. We can make the style changes above as other issues or
just as editiorial liberties if the group thinks they are good ideas.