Subject: [eap] Proposed resolution to Issue 150: Lower Layer Behavior for Limited Access

From: [email-masked] (John Vollbrecht)
Date: Mon, 04 Aug 2003 15:04:04 -0400

As Bernard points out, I think the need for implementation independence is 
required for a standard.  However, if I understand Yohihiro's issue 
correctly, I think the question is more about what the lower layer is than 
about independence.  A suggestion below for change.  First a couple 
comments.

If the lower layer asks if what the user can do, then the response might be

a. connect to the world
b. connect to the walled garden
c. no connection available

I think case a/c is the normal case, and is what Bernard is considering. 
However, case a/b is what I think Yoshihiro may be considering.
In case b the user imay be connected to the local net but not the Internet. 

I think EAP is set to say "yes" (possibly with conditions [authenticate and 
authorize]),  or no.  Assuming EAP says "yes" or "no", the question being 
answered is important.  The question might be "should I grand access" [case 
a/c]] or "should I grant Internet Access" [case a/b].

It is case b that seems interesting in the request.  The text assumes case 
a/c.  I think not referring to the lower layer may satisfy both sides.  My 
suggestion is as follows:
change:

> "On the peer, once the method completes unsuccessfully (that is,
> either the authenticator sends a method-specific failure indication,
> or the peer decides that it does want to continue the conversation,
> possibly after sending a method-specific failure indication), the peer
> MUST terminate the conversation and avoid sending data on the link."

to

 "On the peer, once the method completes unsuccessfully (that is,
 either the authenticator sends a method-specific failure indication,
 or the peer decides that it does want to continue the conversation,
 possibly after sending a method-specific failure indication), the peer
 MUST terminate the conversation and indicate failure to the lower layer."

-- John

--On Saturday, August 2, 2003 7:47 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> The text of Issue 150 is enclosed below.
>
> I don't think that the intent of section 7.9 is to make the interpretation
> of EAP Failure implementation dependent -- this is the kind of thing that
> needs to be standardized in order for the protocol to be interoperable.

I am thinking that the change to EAP would be to take out the
> Allowing the peer to activate the link after receiving an indication
> that the authenticator is not granting access seems dangerous because it
> would be likely to either open the door to rogue authenticators or to
> timeouts where the peer would attempt to obtain an IP address and fail,
> leaving the user in limbo.
>
> My recommendation is that this change be rejected.
>
> ------------------------------------------------------------------
> Issue 150: Lower Layer Behavior for Limited Access
> Submitter name: Yoshihiro Ohba
> Submitter email address: [email-masked]
> Date first submitted: June 18, 2003
> Reference:
> Document: EAP-04
> Comment type: T
> Priority: 1
> Section: 4.2
> Rationale/Explanation of issue:
>
> Text in section 7.9 allows limited access for peer after completion of
> EAP authentication with failure, with stating that the interaction of
> EAP with lower layers are highly implementation dependent.
>
> On the other hand, the following text in section 4.2 contains
> some wording that does not seem to consistent with section 7.9.
>
> "On the peer, once the method completes unsuccessfully (that is,
> either the authenticator sends a method-specific failure indication,
> or the peer decides that it does want to continue the conversation,
> possibly after sending a method-specific failure indication), the peer
> MUST terminate the conversation and avoid sending data on the link."
>
> I think whether the peer avoids sending data on the link is a sort of
> thing that should be described in each lower-layer protocol that
> carries EAP, since this is heavily lower-layer dependent as described
> in section 7.9.  In fact, if the peer avoids sending data on the link,
> limited access scenario cannot be realized (though it might depend on
> the definition of "link").  In sectioni 4.2, it is described that a
> backend EAP server can send EAP Success when it does not need to
> authenticate the peer, but how it can determine it does not need to
> authenticate the peer in a roaming environment where it might be
> difficult for the EAP server to know the network access policy on the
> remote NAS?  I know this issue was recently discussed and section 4.2
> was updated to reflect the discussion, but I still find an
> inconsistency that should be resolved.
>
> Requested change:
>
> Remove "and avoid sending data on the link".
>
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Yoshihiro Ohba)
Date: Mon, 04 Aug 2003 12:55:55 -0700

The new text proposed by John works fine with me.

Yoshihiro Ohba