Subject: [eap] Proposed resolution to Issue 66: Mandatory for who?

From: [email-masked] (Bernard Aboba)
Date: Thu, 9 Jan 2003 07:56:43 -0800 (PST)

On re-reading RFC 2284, it would appear to me that the document is
relatively clear about the obligations of peer and authenticator EAP
implementations. Rarely is the term "authenticator" used when "backend
authentication server" is intended. To make this crystal clear, I would
propose the following resolution to this issue:

In Section 1, add:

"Within this document, authenticator requirements apply regardless of
whether the authenticator is operating as a pass-through. Where the
requirement is meant to apply to either the authenticator or
backend authentication server, depending on where the EAP authentication
is terminated, the term "EAP server" will be used."

In Section 1.2, add:

"EAP Server

The entity that terminates the EAP authentication with the peer.
In the case where there is no backend authentication server, this
term is synonymous with "authenticator". Where the authenticator
operates in pass-through, it is synonymous with
"backend authentication server".

In Section 5.4, change:

"All EAP implementations MUST support the MD5-Challenge mechanism."

To:

"EAP peers, authenticators and backend authentication servers
MUST support the MD5-Challenge mechanism."

Add in Section 4.1:

"These obligations apply regardless of whether pass-through
is implemented. The EAP authenticator is responsible for
retransmitting Request messages. If the Request message is
obtained from elsewhere (such as from a backend authentication
server), then the authenticator will need to
save a copy of the Request in order to accomplish this. The
authenticator is also responsible for discarding Response messages
with the wrong Identifier value before acting on them in any way,
including passing them on to the backend authentication server for
verification. Similarly, the peer is responsible for detecting and
handling duplicate Request messages before processing them in any
way, including passing them on to an outside party."

------------------------------------------------------------------------
Issue 66: Mandatory for who?
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 8, 2003
Document: http://mail.frascone.com/pipermail/eap/2003-January/000514.html
Comment type: T
Priority: S
Section: 3.4
Rationale/Explanation of issue:

RFC 2284, Section 3.4 states:

"All EAP implementations MUST support the MD5-Challenge mechanism."

Does this obligation extend to NASes operating in passthrough mode?
For example, MUST they be able to authenticate a local user via
EAP MD5?

Going further, do obligations of authenticators (such as dropping
duplicate Requests) extend to NASes operating in passthrough? Who
is the authenticator in this case? The NAS? The AAA server?
Both?

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 12:26:13 -0500

> "backend authentication server".

OK.

> MUST support the MD5-Challenge mechanism."

I still think that's too strong.  An EAP Authenticator implementation
that *always* does pass-through and *always* uses a backend mechanism
that supports MD5-Challenge would thus be rendered non-compliant.

> way, including passing them on to an outside party."

OK.

-- 
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 08:28:21 -0800 (PST)

> that supports MD5-Challenge would thus be rendered non-compliant.

Since the original RFC 2284 text uses the words "EAP implementation", it's
hard to argue that an authenticator operating in pass-through mode doesn't
implement EAP. So it seems to me that the obligation applies.

I'd also note that there may be sound technical reasons for it to apply.
An EAP implementation that doesn't support the mandatory-to-implement
authentication method is incapable of operating without a backend
authentication server, an optional feature of EAP. Encouraging the
creation of devices like that is a bad idea, because interoperability is
then not guaranteed in a number of scenarios.

For example, even if the device might operate in pass-through for peers,
it might want to authenticate a device on another interface. An example is
a switch, which might need to authenticate another switch on a trunk port.
Although it operates purely in pass-through for peers, to authenticate
another switch, it needs to implement the mandatory method.

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 13:42:30 -0500

> implement EAP. So it seems to me that the obligation applies.

Not so hard for me -- the "EAP implementation" in this context
encompasses the NAS innards as well as the capabilities and issues of
the backend security system.

As I said before, the rationale for this requirement was to ensure the
*possibility* of interoperability between EAP Authenticatees and EAP
Authenticators.  It doesn't, and by design cannot, ensure this
interoperability in any particular deployment.  For instance, I might
disable MD5-Challenge support through an administrative interface.  Or
I might just neglect to put any credentials at all into the
MD5-Challenge authentication database.  The possibility of these
scenarios doesn't negate the requirement.

> authentication server, an optional feature of EAP.

I disagree with that.  It may well make perfect sense for *SOME*
implementors to create EAP Authenticators that are incapable of
operation without a backend service.  This is no different from the
situation the customer has when he unwraps the shrink-wrap on his
brand-new EAP Authenticator with built-in MD5-Challenge -- that new
box can't possibly already have all the client keys hard-coded into
it, so it's not "interoperable" by the standards you're asserting.

Consider, for example, an access device that has *no* local storage
whatsoever.  It has an EAP Authenticator and a AAA Client burned into
ROM, and has no provision for use in any other way.  Are we really
trying to say that such a device is "illegal" by this standard?  Why?

I think all of this is missing the point.  The point is that from the
point of view of the *wire*, it must be the case that the
implementations on each end of that wire *can* be configured such that
they are willing to support MD5-Challenge.  If there's magic that
happens within or behind the implementation, whether that's user
prompting, file reading, Tarot cards, AAA access, SQL queries, or
anything else, that's immaterial.

Think of it as a software version of a Thevenin equivalent.  ;-}

> Encouraging the

Interoperability failure is already guaranteed in the scenario where
the Authenticatee doesn't have the right credentials to authenticate
to the Authenticator.  How is this lack-of-implementation-required-
backend situation substantially different?  I don't think that it is.
If your authentication database is unavailable, you're not going to be
able to do too many good things.

Suppose I have an EAP Authenticator implementation that *DOES* include
MD5-Challenge.  However, the implementation is designed such that it
*MUST* be configured with the address of a TFTP server that gives
access to the credentials for authentication.  Note that EAP is
terminated right on this device, and the inclusion of MD5-Challenge in
this implementation makes it "compliant" with the RFC requirements.
Suppose now that that TFTP server is down.

Does this hypothetical implementation fail the RFC test?

> another switch, it needs to implement the mandatory method.

I assume you're saying that the pass-through AAA data flows over that
trunk port, and thus the implementor ends up with a chicken-and-egg
problem in authenticating that trunk port since he can't pass his AAA
data yet.

That's an implementation error.  Such an implementation must either
provide an alternative mechanism for that trunk port, or simply not
authenticate that port with EAP.

I don't think legislating intelligence on the part of designers is
likely to be successful.

---

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

> the backend security system.

Maybe this use of "implementation" is a special case where it refers to
the peer and EAP server implementations (wherever the EAP server is
implemented).

Elsewhere in RFC 2284, where the word is used, it seems to apply to the
peer and authenticator alone:

"If authentication of
the link is desired, an implementation MUST specify the
Authentication-Protocol Configuration Option during Link
Establishment phase."

or

"silently discard
             This means the implementation discards the packet without
             further processing.  The implementation SHOULD provide the
             capability of logging the error, including the contents of
             the silently discarded packet, and SHOULD record the event
             in a statistics counter."

> unless it affects on the wire...

If you go down this road, then it's hard to simultaneously argue that the
duplicate elimination problem can be resolved by requiring the
authenticator to behave the same way regardless of whether it is in
pass-through mode or not. After all, from an on-the-wire perspective, the
conversation between peer and authenticator looks the same either way,
right?

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 14:15:47 -0500

> Authentication-Protocol Configuration Option during Link

No, I can't follow you there.  The implementation MUST issue this
message, because it's the only thing attached to the L2 link.  What
that text doesn't say -- and can't say -- is how the "desire" is
determined.  That may well involve access to policy databases that are
not coresident with the EAP implementation.

> conversation between peer and authenticator looks the same either way,

Right.  This is exactly why I've also consistently argued that
specifying how pass-through might work is merely an *implementation*
guideline, and not specifically an EAP issue.  "If you're doing this,
here's what we think the best, but perhaps not only, strategy might
be."

Note also that it's a good guideline because the way DIAMETER works
actually *prevents* it from ever doing the Request retransmissions
itself.  There's no way for a DIAMETER server (at least that I know
of) to send an unbidden "answer" that would be required to implement
such a thing.  Even if it were possible, it's passing strange that the
DIAMETER server somehow "knows" the link characteristics of that
client 1,000 miles away.  As long as retransmissions are in the NAS,
it seems questionable at best to have "duplicate" (really: wrong
Identifier) detection of the Reponses done anywhere else.

Plus, of course, relaying along data that you rightfully know to be
garbage (Response Identifier != last sent Request) is just a bad plan.
It serves no purpose at all.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 9 Jan 2003 10:22:43 -0800 (PST)

> not coresident with the EAP implementation.

OK. I think the answer is that a device which does pass-through only, need
not implement the mandatory method. However, one which implements both
pass-through and local authentication does need to implement the mandatory
method. Does that make sense?

> here's what we think the best, but perhaps not only, strategy might

Yes. Specifying the operation of pass-through is the job of RFC 2869bis.

> itself.

Yes.

> Even if it were possible, it's passing strange that the
> client 1,000 miles away.

The issue does come up though, where the EAP packet is potentially larger
than the link MTU. In that case the Diameter or RADIUS server needs to
figure out what the link MTU is, so as to limit the packet size
appropriately. This is usually accomplished via a "hint" from the NAS.

> It serves no purpose at all.

Yes.

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 14:56:24 -0500

> method. Does that make sense?

That's a good issue.  I'd have to say that as long as the backend
authentication mechanism (pass-through or otherwise) is one that can
allows the use of MD5-Challenge (i.e., the underlying AAA protocol has
some support for it), then this would fulfill the requirement.  If one
picked a mechanism (e.g., NIS) that didn't, then that would be a
problem.

> Yes. Specifying the operation of pass-through is the job of RFC 2869bis.

That sounds right to me.

> appropriately. This is usually accomplished via a "hint" from the NAS.

Agreed, though that's a slightly different issue.  The link MTU is
generally pretty simple.  It doesn't change much.  The RTT may vary
wildly, depending on conditions.  Plus, as noted before, the AAA
connection itself has its own reliability.  So, what you'd end up with
is one retransmission-based reliable protocol (EAP) running atop
another (AAA), with one having the RTT of the AAA connection, and the
other having the RTT of the link plus the AAA connection.  If the link
RTT is very small in comparison to the AAA RTT, which is probably a
very likely scenario, then you have two protocols run atop each other
with commensurate RTTs.  That's bad news; it'll oscillate.

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 07:30:37 -0800 (PST)

> picked a mechanism (e.g., NIS) that didn't, then that would be a

OK. How about this:

"EAP peer and EAP server implementations MUST support the MD5-Challenge
mechanism. An authenticator which only supports pass-through is exempt
from this requirement, since it does not act as an EAP server. However, if
the authenticator can be configured to authenticate local users, then
the requirement applies."

---

From: [email-masked] (James Carlson)
Date: Sat, 11 Jan 2003 11:43:59 -0500

> the requirement applies."

That seems good, at least for pass-through.  More broadly, an EAP
authenticator must have at least one backend authentication mechanism
that is capable of supporting MD5-Challenge.  (Which, I think, is
equivalent to saying that the authenticator must support MD5-Challenge
...)

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 07:40:26 -0800 (PST)

How about this:

"EAP peer and EAP server implementations MUST support the
MD5-Challenge mechanism. An authenticator which only supports pass-through
MUST be configured with a backend authentication server that is capable
of supporting MD5-Challenge, although it need not support MD5-Challenge
itself. However, if the authenticator can be configured to authenticate
local users, then the requirement applies."

---

From: [email-masked] (James Carlson)
Date: Sat, 11 Jan 2003 11:55:37 -0500

> local users, then the requirement applies."

How about:

    "EAP peer and EAP server implementations MUST support the
    MD5-Challenge mechanism.  An authenticator that supports only
    pass-through MUST allow communication with a backend
    authentication server that is capable of supporting MD5-Challenge,
    although the EAP authenticator implementation need not support
    MD5-Challenge itself.  However, if the EAP authenticator can be
    configured to authenticate peers via any non-pass-through
    mechanism, then the requirement applies."

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 08:02:48 -0800 (PST)

OK with me.