Subject: [eap] Issue 63: Identifier space advice

From: [email-masked] (Bernard Aboba)
Date: Wed, 8 Jan 2003 08:31:45 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 8, 2003
Document: RFC2869bis-05
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

AAA protocols may not preserve ordering. For example, RADIUS runs
over UDP, an unordered transport. Diameter runs over reliable,
ordered transports, yet ordering may not be preserved in the
event of failover.

Even though RFC 2284bis requires that EAP runs over an ordered
transport, given possible AAA reordering, it is possible for
retransmissions to be reordered in way that will confuse the
EAP authenticator residing on the AAA server.

To fix this, the following language needs to be inserted:

"AAA protocols may not preserve ordering. For example, RADIUS runs
over UDP, an unordered transport. Even where a AAA protocols runs
over reliable, ordered transports, ordering may not be preserved
in the event of failover, where proxies are present.

As a result, where the NAS does not eliminate duplicate responses,
and the EAP Identifier space is not monotonically increasing,
it is possible for the RADIUS server to incorrectly act upon a
duplicate EAP Response. To avoid this, RADIUS servers acting as
EAP servers SHOULD implement a monotonically increasing EAP
Identifier space, so as to be able to silently discard
EAP Responses that arrive out of order."

---

From: [email-masked] (James Carlson)
Date: Wed, 8 Jan 2003 13:04:10 -0500

> EAP Responses that arrive out of order."

As I've said in the meeting, I think this is sliding in exactly the
wrong direction.

EAP has a perfectly good invalid response (including duplication)
detection mechanism on the authenticator side (where the RADIUS
connection would necessarily be; RADIUS doesn't handle
authenticatees).  The EAP mechanism should be used.  As long as you
can detect duplicates, the packets going from authenticatee to
authenticator have no problem.

The only remaining issue is that of generating the duplicates in the
first place.  Perhaps one of the underlying assumptions here might be
that retransmission of EAP Request messages would be driven by the
RADIUS server.  I think that's a bad plan, because it's unnecessary,
exposes the RADIUS server to retransmission timers based on a EAP
peer-to-peer link about which it knows exactly nothing, exposes the
RADIUS server to retransmission timers and duplicate elimination that
draft-ietf-aaa-eap-00 doesn't discuss, increases network traffic, and
doesn't seem to help solve any identifiable problem.

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.

-- 
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] (Yoshihiro Ohba)
Date: Wed, 8 Jan 2003 14:10:28 -0500

> authenticator have no problem.

Based on this, authenticatee also needs additional rule for not
accepting Requests with non-monotonically increasing Identifier when
the authenticator is operating in monotonically increasing Identifier.
Then my concern is how the authenticatee and authenticator can tell
whether ordered delivery is provided over the entire authentication
path between the two entities or not, which seems to me be a hard
thing to do.

> place so that the NAS presents a simple request/response interface to

I agree.

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

Yoshihiro Ohba

---

From: [email-masked] (James Carlson)
Date: Wed, 8 Jan 2003 14:24:07 -0500

> the authenticator is operating in monotonically increasing Identifier.

No, I don't think it does.  If the underlying layer does not reorder,
then there's only the "current request" and a "new request."  There's
no reason to require this.

(Indeed, requiring this breaks compatibility with RFC 2284, which does
*not* place restrictions on Identifier choice by the authenticator.  I
agree that this, along with some definiton of windowed ID comparision,
is necessary if you allow reordering.  2284 didn't and I don't think
we should or even can without writing essentially a new protocol.)

> path between the two entities or not, which seems to me be a hard

Agreed.  So, you break it into two components: there's the EAP
peer-to-peer (L2) connection, and the EAP authenticator-to-AAA-server
connection.  The EAP peer-to-peer connection cannot result in
processing of duplicates, because the Identifier and the
non-reordering requirement together don't allow that to happen.

The EAP authenticator-to-AAA-server connection is just out of scope.
There's clearly a requirement that a AAA protocol must somehow
describe how it will support the EAP authentication "as if" the
authenticator were a single integrated system (including any
AAA-related ordering), but I don't see how that's an issue for EAP
itself.  The connection between these two isn't exactly EAP; it's
encapsulated EAP messages within a AAA transport.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 8 Jan 2003 16:38:59 -0800 (PST)

> authenticator have no problem.

The question was whether the requirements on the authenticator apply to
the NAS when it operates in passthrough, or to the AAA server. While IEEE
802.1X *does* do duplicate elimination on the NAS, it is not clear whether
that is mandated by the current RFC 2284bis text. If we can
require the NAS to fulfill the obligations of an authenticator whether it
is doing pass-through or not, then you are correct.

> RADIUS server.

No. RFC 2865 is very clear that RADIUS retransmission is driven by the
NAS.

> place so that the NAS presents a simple request/response interface to

Yes, I would agree. The question in my mind is whether this is an RFC
2284bis obligation on an authenticator, or whether it is a AAA client
obligation. My sense is that it is a AAA client obligation.

I'd note that this is not the only case in which the obligations of
"authenticators" are unclear. Another example is the obligation to
implement the mandatory to implement method (EAP MD5). Is this an
obligation of a NAS that always acts as a pass through or a AAA server
obligation?

---

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

> is doing pass-through or not, then you are correct.

I think the issue has more to do with the definition of the AAA server
and client responsibilities that are designed into the AAA
architecture itself.  In other words, it's just not our problem.

> No. RFC 2865 is very clear that RADIUS retransmission is driven by the

I'm trying to guess at why it's even considered an issue.  The idea
that there's some sort of a problem here is rather foreign to me.  I
can't think of a plausible system architecture in which an EAP
Authenticator implementation passes along garbage to its backend
authentication server.  That makes no sense, so I'm trying to guess at
how it might have been considered an issue.

If someone here thinks that bad responses (there are no
distinguishable "duplicates" at the Authenticator side; they're just
lumped together with all Responses that have the wrong, non-current
Identifier value) should be passed along to the AAA service, please
speak up and explain.

> obligation. My sense is that it is a AAA client obligation.

Exactly.

> obligation of a NAS that always acts as a pass through or a AAA server

The EAP Authenticator has an obligation to provide this.  If the
chosen AAA server can't do it, then either the EAP Authenticator
cannot use that AAA server, or the EAP implementation needs a
proprietary work-around.  The only issue we should care about is the
messages between EAP Authenticator and EAP Authenticatee.

For instance, suppose the EAP Authenticator is implemented on a system
using NIS for "user" authentication.  I don't know of any feasible way
to make that interface work with MD5-Challenge.  So, as an EAP
implementor, I'm stuck with a problem: I must support MD5-Challenge,
and my chosen backend doesn't support that requirement.  Thus, I have
to kludge something together, like a separate text file with
MD5-Challenge credentials.

Now, is that an RFC issue?  I don't think so.  The responsibility for
the EAP implementor is clear.  How you might achieve that through
implementation choices is your problem.