Subject: [eap] Issue 198: Other EAP Peer SM Issues

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Nov 2003 08:20:00 -0800 (PST)

Issue 198: Other EAP Peer SM issues
Submitter name: Ashwin Palekar
Submitter email address: [email-masked]
Date first submitted: Nov 11, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-November/001831.html
Document: SM-01
Comment type: T
Priority: S
Section: 4
Rationale/Explanation of issue:

The IDENTITY method is independent of the method being negotiated. How do
we deal with the case where different methods require different
identities?

During EAP authentication sequences, the server can ask for different
identities for different eap methods  how does the client know which
identity it is supposed to provide?

clientTimeout  who is responsible for setting this? Is this set per
request, per eap host, or is it based on some other criteria?

eapTunnelled. Who sets this? It is not clear to me.

Does the SM behavior when eapTunnelled is set really correspond to that of
existing tunneled methods? I don't think so.

Is portEnabled condition generic enough? Can it apply to any media, such
as PPP?

Why do we have allowNotification condition? Whats the use case that a
specific eap method turns it on/off? Or is this an EAP setting?

Chapter 4.2, in methodState=Done, it says The method always continues at
this point. I think it should be ends instead.

This document only provides timeout and keys to application. In protocols
such as PEAP, other information is also returned such as EAP TLV.  So
perhaps the text on interfaces between EAP and methods should be clear
that this is extensible.

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 Nov 2003 10:59:51 -0800

> we deal with the case where different methods require different

The case is supposed to be handled by each method with defining
method-specific identity handling.  It might be better to explicitly
mention this in the statemachines draft.

> identity it is supposed to provide?

The same as above.

> request, per eap host, or is it based on some other criteria?

I think the draft is not clear on this.  The current peer state
machine reads that idleWhile variable is set to clientTimerout value
even when the peer receives an invalid EAP message, which should not
actually change the timer value.

Speaking about my EAP peer implementation, the clientTimeout can be
set either by applications that use the EAP peer state machine or by
EAP methods.  The idleWhile timer is set only when the state enters
"IDLE" state from "INITIALIZE" state.

> existing tunneled methods? I don't think so.

I agree. The variable eapTunnelled is defined without describing how
sequence of methods inside a tunneling method can be supported with
this state machine.  I think we need to do one of the following:

o Remove eapTunneled variable.

o Describe details on how sequence of methods inside a tunneling
method is supported.

If doing the latter is a hard thing, I would suggest just removing the
eapTunneled variable.  But if the latter can be easily done, it might
be helpful to describe more about sequencing.

> Is portEnabled condition generic enough? Can it apply to any media, such

I don't think portEnabled condition is generic enough.  PANA and
IKEv2 do not have a notion of port.  My implementation uses more
generic "Start()" and "Restart()" functions in the API, which modify
portEnabled and eapRestart conditions (i.e., the variables are used
just to follow the state machine draft, not really necessary IMHO.)

> specific eap method turns it on/off? Or is this an EAP setting?

According to the description in section 5.2 of RFC2284bis, this is
basically eap method settings (except that EAP peer state machine just
initializes the condition to TRUE).

> this point. I think it should be ends instead.

I agree.

> perhaps the text on interfaces between EAP and methods should be clear

Perhaps if we add the following text in section 8 "Implementation
Considerations", that should be sufficient:

"Implementations may define an additional interface to pass
method-specific information between methods and applications.  Such
method-specific interface definition can be left to implementations
and thus is not defined in this document."

Yoshihiro Ohba