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

From: [email-masked] (Bernard Aboba)
Date: Sat, 2 Aug 2003 19:47:08 -0700 (PDT)

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.

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

---

From: [email-masked] (Yoshihiro Ohba)
Date: Sat, 02 Aug 2003 21:22:56 -0700

I believe that the behavior on whether to "avoid sending data on the
link or not" should be better specified in each EAP transport
protocol, not in RFC2284 bis.  I agree that when IEEE 802.1X is used
the supplicant must avoid sending data on the link if EAP
authentication fails, because it is the port-based access control
model IEEE 802.1X defines.  On the other hand, when PANA is used as
the EAP transport, the PANA client may already obtain an IP address
and is using the link (with a limited access) before EAP
authentication occurs and thus "avoid sending data on the link" for
the link already in use does not make sense.  

The suggested change is actually needed for PANA to support a scenario
described in section 4.6. "Limited free access" of
draft-ietf-pana-usage-scenarios-06.txt which is now in the IESG review
after completing WGLC.

EAP is an authentication protocol but "avoid sending data on the link"
(which is a task of access control) is beyond the task of
authentication protocol, thus the text should not be included in
RFC2284bis.

Yoshihiro Ohba

On Sat, Aug 02, 2003 at 07:47:08PM -0700, Bernard Aboba wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap