Subject: [eap] Issue 63: Identifier space advice

From: [email-masked] (Bernard Aboba)
Date: Wed, 8 Jan 2003 20:23:00 -0800 (PST)

> Assuming the duplicates are generated in the same place (the NAS
> sending and resending the same EAP Request over and over to provoke a
> Response), I think the duplicates should be eliminated in the same
> place so that the NAS presents a simple request/response interface to
> any backend service.

Looking through RFC 2284bis again, I believe that the requirements on
authenticators apply whether the authenticator is operating in pass
through mode or not. The definition of an authenticator makes no such
destinction. Maybe we should say that explicitly: that the "mode" of
operation is irrelevant.

Also, the definition of an RFC 2284bis authenticator is identical to that
in IEEE 802.1X -- nowhere in the document does it use the term
"authenticator" where "backend authentication server" is meant. So there's
no terminology disconnect that I can see.

Given this, there is an obligation of the NAS to drop duplicate
Responses, whether it is talking to a backend authentication server or
not. If made clear, this resolves the issue.

However, I will say that there appears to be widespread confusion on this
issue (as well as on whether the mandatory-to-implement method needs to be
implemented by a NAS in passthrough -- the answer seems to be yes). So
clarification is needed.

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 08:59:58 -0500

> destinction. Maybe we should say that explicitly: that the "mode" of

Right.  I fully agree with that -- whether it's a "pass-through" or
not is irrelevant.  This document describes how EAP has to behave on
the wire between two EAP speakers, and, for interoperability, the that
part of the behavior must *not* change depending on factors outside of
this link.  The linkage between the authenticator and any backend
authentication services -- whether using AAA pass-through, translation
to foreign protocol (such as, say, LDAP), proprietary database, or
random number generation -- must be invisible to the authenticatee.

> implemented by a NAS in passthrough -- the answer seems to be yes). So

That sounds like a reasonable plan.  The text should say that the EAP
Authenticator is responsible for retransmitting the Request messages,
and that if it got the Request message from someone else (i.e., via
AAA), then it will have to save a copy in order to do this, and that
the Authenticator is responsible for discarding Response messages with
the wrong Identifier value before acting on them in any way, including
passing along to an outside party for verification.  Similarly, the
EAP Authenticatee is responsible for detecting and handling duplicate
Request messages before processing them in any way, including passing
along to any outside party for fetching data.

Of course, I still think this is just internal design advice.  It
should not be normative because it still doesn't describe on the wire
behavior.

We probably need a term to disambiguate the "ultimate authenticator"
(which might be a AAA server) from the EAP Authenticator
(peer-to-peer) role.  Any suggestions?

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 9 Jan 2003 06:57:50 -0800 (PST)

> (peer-to-peer) role.  Any suggestions?

The term "EAP Server" is used in RFC 2869bis. However, we have to be
careful where this is applied. I'll look through RFC 2284bis for any
places where that is meant instead of "authenticator". At first glance,
there aren't many cases of this.