Subject: [eap] Implementer Survey: Duplicate detection in pass-through

From: [email-masked] (Bernard Aboba)
Date: Sun, 9 Feb 2003 13:17:48 -0800 (PST)

As a step toward resolution of Issue 74, I would like to ask implementers
of EAP Authenticators supporting pass-through mode how they implementation
Duplicate detection. For example:

a. Do you perform duplicate Response detection on the authenticator prior
to forwarding Responses to the authentication server?

b. If so, can you provide details of how a duplicate is determined? Is
this based solely on the Identifier value? Does it matter if the duplicate
is received before or after another Request is sent?

---

From: [email-masked] (James Carlson)
Date: Sun, 9 Feb 2003 17:53:03 -0500

> to forwarding Responses to the authentication server?

I don't have a pass-through implementation, but I do think there's a
problem with the wording of this survey.

There's no such thing as "duplicate Response detection."  The only
thing one can detect here is a Response with an invalid ID -- an
Identifier value that does not match the last Request.  Unmatching
messages *might* be duplicates, but may also be any sort of arbitrary
unexpected message.

The issue of duplicate detection, as defined by EAP, matters only for
Request messages, and then only on the authenticatee side, where,
presumably, nobody has a pass-through implementation.

I think that question should read:

	a. Do you discard any received Response messages that have an
	   invalid Identifier field, or do you pass these along to the
	   authentication server?

... of course, with that wording, I doubt that anyone would consider
the pass-through behavior in the latter case to be anything other than
a bug.

-- 
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: Sun, 9 Feb 2003 14:24:17 -0800 (PST)

> the pass-through behavior in the latter case to be anything other than

Assuming that there is an outstanding Request, why would a received
Response message with a matching Identifier field be considered invalid?
The Identifier doesn't change until another Request is sent.

By this logic, it would seem that the authenticator operating in
pass-through should forward any Response message with a matching
Identifier field; but once a Request is sent, the Response messages would
be considered invalid, and not forwarded.

---

From: [email-masked] (James Carlson)
Date: Mon, 10 Feb 2003 06:25:41 -0500

> The Identifier doesn't change until another Request is sent.

Once you've got a Response to a given Request, there can be no more
valid Responses -- you're done.

This feels like familiar ground.  What we're looking at here is time
skew.  From the point of view of the authenticator, this case cannot
occur.  Once you receive a valid Response message (one that has an
Identifier field that is equal to the Identifier in the last
transmitted Request), you are then required to send the next Request
or the Success/Failure termination.  There's no case in which you've
received a Response and you're just pondering what's next.

If you extend this mechanism through intermediaries, I don't see how
or why the model should be any different.  Once the valid Response is
seen, that round is done.

> be considered invalid, and not forwarded.

This certainly sounds to me like another MIC-related issue -- that is,
one that pops up only because the security model has been altered from
the original EAP design to include the possibility of a man-in-the-
middle attacker.  Otherwise, why would you care about the treatment of
"duplicate" responses?

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 10 Feb 2003 05:10:22 -0800 (PST)

> valid Responses -- you're done.

I would agree to that once the EAP server has gotten a *valid* Response to
a given Request -- because at that point the Identifier has changed. But the
question is what the behavior is on an authenticator in pass through mode.
It can't know that the Response that it just forwarded to the
authentication server is valid or not -- and it doesn't know what the
new Identifier is.

> transmitted Request),

I'd claim that a valid Response requires more than just a valid
Identifier.

> you are then required to send the next Request

For a valid Response, that is true.

> seen, that round is done.

It is different because the intermediary can only determine the
validity of the Response when it receives a new Request from the
authentication server. It's at that point that the Identifier changes.

> This certainly sounds to me like another MIC-related issue -- that is,

Yes, it is.

---

From: [email-masked] (James Carlson)
Date: Mon, 10 Feb 2003 09:40:25 -0500

> authentication server is valid or not -- and it doesn't know what the

I don't follow.

The EAP server in pass-through mode must certainly know what a valid
Identifier value looks like.  It must know this because it is the one
that is performing Request retransmissions, and thus it has a copy of
the most recent Request sent.  (We've already established that this
cannot be driven by DIAMETER or RADIUS, correct?)

If you're proposing that somehow the authenticatee can generate a
Response with an Identifier that corresponds to a Request that it has
not yet seen, and have these two cross in flight, I don't think I
understand why it would be useful to support that.

> I'd claim that a valid Response requires more than just a valid

RFC 2284 would claim otherwise.  There are four clear cases:

	- Packet is hopelessly mangled and unrecognizable -- drop.

	- Identifier field is wrong -- drop.

	- Identifier field is right, but contents are wrong.  Send
          Failure.

	- Identifier field and contents are right.  Send Success.

You're proposing a fifth possibility here -- Identifier is correct but
contents are wrong, and yet we're just going to drop it.  I don't see
how that's a valid thing to do.

Moreover, this case seems to exist solely for the purpose of
supporting MICs.  In that case, why not define the MIC such that the
pass-through device is in on the game?  In other words, why not define
these protocols such that you can have the EAP server do the MIC
validation before ever passing the data along to the authenticator?

> authentication server. It's at that point that the Identifier changes.

That doesn't actually matter, because it can't possibly get any valid
Response messages to that new Request until it's seen the new Request
and forwarded it along.  At that point, it knows the new Identifier
value of interest.

The assumption here seems to be that the EAP server doesn't support
the MIC feature and that (somehow) the Identifier value serves as a
cleartext MIC-like thing.  Considering the absurd lengths that folks
will go to in order to reduce load on authentication servers
(lightweight rechallenges, short hold, and such), that seems to me to
be the wrong sort of direction to head because it allows attackers
connected to distributed EAP servers to inundate a central
authenticator with garbage to validate and discard.

Thought experiment: suppose you did have the EAP server functionality
as you propose, and the EAP server passed through all messages with
the current Identifier value until a new Request was seen.  You've
previously said that it's "illegal" for an authenticator to offer a
new EAP Request without having received a Response to its last one.[1]
How does the EAP server, which is not privy to the validity of the
Response messages, know when it can pass along a new Request and when
it cannot?  Does this mechanism violate the never-change-type-
midstream requirement?

[1] And I still disagree that this is the right thing to do.  I still
    see no reason to disallow this RFC 2284-compliant behavior.

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 10 Feb 2003 05:54:49 -0800 (PST)

> cannot be driven by DIAMETER or RADIUS, correct?)

Yes, retransmission cannot be driven by AAA.

And yes, the authenticator knows that the currently valid Identifier is,
regardless of the mode. The question is the precise moment at which that
Identifier value *changes*. The claim is that when the authenticator isn't
in pass-through, that moment occurs when it receives a valid Response,
with validity including *all* checks made on the packet (including a MIC).
If the packet fails any of the validity checks, it is silently discarded
as if it was never sent. In this case that would mean that the
Identifier doesn't change and the authenticator will retransmit the
Request.

When the authenticator operates in pass-through, the claim is that the
Identifier doesn't change until a valid Request is received from the
authentication server.

> 	- Identifier field is right, but contents are wrong.  Send

Where in RFC 2284 does it indicate this?

> how that's a valid thing to do.

The text you added on processing of MICs indicates this course of action,
no?

> pass-through device is in on the game?

That would only be possible if the MIC was in EAP itself, rather than
within a method. Otherwise the authenticator will have to have EAP-method
specific knowledge to check the MIC.

> and forwarded it along.  At that point, it knows the new Identifier

Yes.

> cleartext MIC-like thing.

The assumption is that the authentication server does support the EAP
method-specific MIC, and that by sending a Request it is implicitly
indicating that it has found the previous Response valid.

> authenticator with garbage to validate and discard.

One way to judge the vulnerability to DoS is to look at the ratio of
cycles required for the attack versus those consumed on the target.
Checking a MIC is a relatively lightweight operation compared to say, a
public key operation which will often occur early in the method. So it is
actually less expensive for the method to check the MIC and silently
discard than it is to fail authentication, and presumably have to do the
entire method over again, including the public key operations.

That means that failure is not a more secure approach, and more
advanced protocols almost always prefer silent discard. Look at IKE
(silent discard) vs. TLS (MIC as fatal error); AES CCMP (silent discard)
vs. TKIP (counter-measures).

> Thought experiment: suppose you did have the authenticator functionality
> as you propose, and the authenticator passed through all messages with
> the current Identifier value until a new Request was seen.

Actually, what is being proposed is that the authenticator passes through
the first Response; if it receives a new Request, the Identifier changes
and additional Responses with the old Identifier are discarded. It only
forwards additional Responses with the matching Identifier if the
authentication server indicates that the initially forwarded Response is
invalid.

> new EAP Request without having received a Response to its last one.[1]

Actually, we're proposing to remove that.

> How does the authenticator, which is not privy to the validity of the
> it cannot?

When it receives a new Request, it forwards it to the peer.

> Does this mechanism violate the never-change-type-
> midstream requirement?

I don't think so.

---

From: [email-masked] (James Carlson)
Date: Mon, 10 Feb 2003 12:14:06 -0500

> Where in RFC 2284 does it indicate this?

The first case is just basic networking; it's implied.  (For example,
if the Length field indicates that the message is *longer* than the
actual message received, then the implementation MUST silently discard
the malformed message.  Not in the text, but obviously implied.)

The second case is in 2.2.1 -- "The Identifier field of the Response
MUST match that of the Request."

The third case is in 2.2.2 -- "If the authenticator cannot
authenticate the peer (unacceptable Responses to one or more Requests)
then the implementation MUST transmit an EAP packet with the Code
field set to 4 (Failure)."

> The text you added on processing of MICs indicates this course of action,

No.  Perhaps there's still imprecision in the text.

I view MICs as being identical to other frame integrity checks in
terms of their position in the architecture.  It's the responsibility
of the receiver (the EAP server, in this case) to perform those checks
before passing the message along.

I don't see this as being terribly different from what the peer is
required to do if the packets are completely malformed (what do you do
with a message whose Length exceeds the size of the actual data, or
with one that has a bad CRC?), nor different from what you do with
(for example) IP datagrams that have a bad header checksum at an
intermediate hop.  You drop.

> specific knowledge to check the MIC.

Not necessarily.  It implies that the protocol used to separate the
EAP server from the authenticator needs to convey the MIC-related
data from the authenticator to the EAP server.

In other words, it's not different from the shared-key derivation
problem or from the "how does the EAP server know to trust the AAA
server when the latter says Success?" problem.

> indicating that it has found the previous Response valid.

That's not necessarily true.  A good implementation should fake its
way through the rest of the sequence, if possible, in order to deny an
attacker additional information.  If you fail part way through, then
you are telling your attacker what bits of his attack are incorrect.

> entire method over again, including the public key operations.

Note that we have a distributed attacker and a centralized target
here.

> vs. TKIP (counter-measures).

That's not the question.  The question is *where* the discard ought to
be done, not *if*.

> authentication server indicates that the initially forwarded Response is

How does the authentication server indicate that the initially
forwarded Response was invalid?

If the authentication server sends a new Request to issue to the
authenticatee, with or without a new Identifier, then I'd argue that
this finishes the problem -- no special handling is required at all
because now the EAP server can do the "right" thing and let through
exactly one Response.

> Actually, we're proposing to remove that.

That sounds good.

> When it receives a new Request, it forwards it to the peer.

Then no new mechanism is needed here on the EAP server, because this
devolves to the already-known case: authenticator sends Request, EAP
server forwards exactly one matching Response, and drops all others
(duplicate or otherwise) until the next Request is received from the
authentication server.

(Not that I'm arguing that this MIC-related stuff is a good thing.  It
seems to be based on questionable assumptions.)

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 10 Feb 2003 17:54:30 -0800 (PST)

> field set to 4 (Failure)."

It does say "one or more" -- implying that a single unacceptable Response
may not be sufficient to cause transmission of a Failure.

> intermediate hop.  You drop.

Certainly if there is no authentication server, that is the case. With an
authentication server there are checks that can't be done on the
authenticator, only the authentication server.

> authentication server from the authenticator needs to convey the
> MIC-related data from the authenticator to the authentication server.

Well, it already does that, by encapsulating the EAP packet, and sending
it to the authentication server, no? You'd need to do that anyway, in
order to allow the authentication server to validate the MIC, since it is run
over the packet.

So one can think of the authenticator as sending the "MIC and associated
data" (e.g. the packet) the authentication server for validation. If the
authentication server validates the packet, it sends an Access-Challenge
containing a new EAP Request. If not, it sends an Access-Challenge
containing an EAP-Start.

Does this reformulation somehow change the way the authenticator
functions?

---

From: [email-masked] (James Carlson)
Date: Tue, 11 Feb 2003 07:08:57 -0500

> may not be sufficient to cause transmission of a Failure.

That text cannot be referring to any sort of "duplicate but different
Response," since there's no way for an authenticatee to send an
unbidden Response message.  Instead, that text is really referring to
the retry-on-human-failure mechanism, as described in the very next
sentence in section 2.2.2:

      [...]  An
      authenticator MAY wish to issue multiple Requests before sending a
      Failure response in order to allow for human typing mistakes.

> authenticator, only the authentication server.

Let's drop back to look at the linkage to the authentication server,
since that's one of the gating items here, and let's assume that the
EAP server is unable to validate the MIC.

If you pass along this MIC-failing message, you're sending another
Access-Request message to the server.  The server then (based on the
fact that the message is garbage) must either send Access-Challenge
(and retry the authentication using a *NEW* EAP Request message) or
send Access-Reject.

The reply to the Access-Request itself triggers EAP into sending a new
message.  There's really no way for the access server to say "yeah,
ok, I see your Access-Request message, but the contents are nonsense,
so I'd like you to try sending another one a bit later when you've
come to your senses."

Note that, if you have a broken architecture that allows for the
possibility of men-in-the-middle, your state is really quite trashed
at this point.  The DoS case is fairly obvious -- all the attacker
needs to do is keep the authenticator busy with MIC-failing messages
until the session dies.

Thus, I claim that if MIC is a useful concept at all with EAP, then it
MUST be checked at the EAP server, even if that's running in "pass-
through" mode.  The authenticator may check it as well if it likes, or
apply some stronger or additional checks to it, but the EAP server
must be involved to make the AAA linkage work right.

(I'm not at all sure that MIC is a useful concept, because I think
it's based on an assumption that breaks EAP -- a system that allows
for something other than exactly two communicating peers on a link.)

> order to allow the authentication server to validate the MIC, since it is run

No -- I meant the other way around.  The MIC validation key needs to
be sent from the authenticator to the EAP server so that the EAP
server can discard MIC-failing messages without attempting to issue
new AAA requests for each one.

> Does this reformulation somehow change the way the authenticator

Yes, because it doesn't address the nature of MIC failure.  MIC
failure is not just a "bad access request" -- it's a spurious message
that doesn't originate from the legitimate peer.  It's really quite a
different thing.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 14:27:24 -0500

If I understand this conversation I believe the issue that James is raising 
is that trying to do DOS mitigation on a protocol that was not designed for 
that is of highly questionable value.

The original idea was that we are worried about DOS attacks, so we should 
attempt to allow the protocol to succeed in the face of them.  This leads 
to some fairly complicated schemes which keep a particular authentication 
sequence in the face of "injected" messages.  The end result is that the 
DOS attack is more successful since it can last longer.  It would be better 
to restart the authentication and get it right than try to find the needle 
in the haystack of attacking trash.

I find this argument to be quite persuasive.

--On Tuesday, February 11, 2003 7:08 AM -0500 James Carlson 
<[email-masked]> wrote:

> > It does say "one or more" -- implying that a single unacceptable
> > Response may not be sufficient to cause transmission of a Failure.
>
> > Certainly if there is no authentication server, that is the case. With
> > an authentication server there are checks that can't be done on the
> > order to allow the authentication server to validate the MIC, since it
> > is run over the packet.
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 11 Feb 2003 14:36:25 -0500

> entire method over again, including the public key operations.

That is true in one side.  On the other hand, checking a MIC is a
relatively heavyweight operation compared to flooding the copies of
the same packet with broken MIC.  So I think the proposed solution
will introduce another DoS.  That's why I indicated earlier that "this
is next choice".  The perfect solution is running EAP over secure
lower-layer.  It is getting clear that EAP has some limitation when it
runs over insecure lower-layer.

> vs. TKIP (counter-measures).

IMHO, the behavior in the errornous event depends on the
characteristics of the underlying transport the protection mechanism
runs.  TLS treats MIC error as fatal because it is assumed to run over
reliable transport.  The current discussion seems to be based on the
assumption that EAP always runs over unreliable transport.  But the
assumption does not always hold.

BTW, RFC 2828 does not recommend the term "message integrity check":

   $ message integrity check 
   $ message integrity code 
      (D) ISDs SHOULD NOT use these terms because they mix concepts in a 
      potentially misleading way. (The word "message" is misleading 
      because it suggests that the mechanism is particularly suitable 
      for or limited to electronic mail. The word "code" is misleading 
      because it suggests that either encoding or encryption is 
      involved, or that the term refers to computer software.) Instead, 
      use "checksum", "error detection code", "hash", "keyed hash", 
      "Message Authentication Code", or "protected checksum", depending 
      on what is meant. 

Yoshihiro Ohba

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 11 Feb 2003 17:19:05 -0500

> in the haystack of attacking trash.

Is it really better?  The problem is that once a needle is there, it
is highly possible that the needle is found again after restarting the
authentication...

Yoshihiro Ohba

---

From: [email-masked] (Jari Arkko)
Date: Wed, 12 Feb 2003 00:29:21 +0200

> Identifier doesn't change until a valid Request is received from the

Yes. If we don't do this, then I worry about making the protocol
behave in different ways towards the peer, depending on whether
there's a pass-through or not. If we are directly authenticating
then we wait until we get a packet that is good in all aspects.
If there's a pass-through in the middle then we only wait until
we get a packet that passes the EAP level tests -- identifier
values and so on.

I'm not sure this brings any specific problems to us, but
I'd rather avoid if possible. This would indicate that
we should either search for a solution that tries to
provide the same functionality in both cases, or try to avoid
"survivable" tests at the method layer.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 13:49:09 -0800 (PST)

> we get a packet that passes the EAP level tests -- identifier

The question is whether that "packet" is a Response or a Request.

> "survivable" tests at the method layer.

I believe that waiting for the Request provides some uniformity in both
cases.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 18:19:54 -0500

--On Tuesday, February 11, 2003 5:19 PM -0500 Yoshihiro Ohba 
<[email-masked]> wrote:

> > If I understand this conversation I believe the issue that James is
> > raising  is that trying to do DOS mitigation on a protocol that was not
> > designed for  that is of highly questionable value.
> >
> > The original idea was that we are worried about DOS attacks, so we
> > should  attempt to allow the protocol to succeed in the face of them.
> > This leads  to some fairly complicated schemes which keep a particular
> > authentication  sequence in the face of "injected" messages.  The end
> > result is that the  DOS attack is more successful since it can last
> > longer.  It would be better  to restart the authentication and get it
> > right than try to find the needle  in the haystack of attacking trash.
>
I am not clear what you mean here.  In my mind the needle would be the one 
good message in a haystack of DOS attacks.  Of course it could be one bad 
message in a haystack of good messages.

I am thinking that restarting the authentication is better in both cases. 
If it is a massive DOS attack restarting takes longer and gives less 
opportunity to use resources.  If it is a single bad message restarting 
once may be simpler and not significantly more expensive.

I think either could be made to work - but without a strong motivation for 
something more complex, I think simple is better.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 11 Feb 2003 18:58:51 -0500

> message in a haystack of good messages.

I meant latter, but it does not really matter which is the needle or
haystack.

> I am thinking that restarting the authentication is better in both cases. 

It seems that if restarting the authentication is needed, it means
that the simple DoS attack succeeds.  Nothing good for users.

Yoshihiro Ohba

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 21:41:12 -0500

--On Wednesday, February 12, 2003 12:29 AM +0200 Jari Arkko 
<[email-masked]> wrote:

> > Identifier value *changes*. The claim is that when the authenticator
> > isn't in pass-through, that moment occurs when it receives a valid
> > Response, with validity including *all* checks made on the packet
> > (including a MIC). If the packet fails any of the validity checks, it
> > is silently discarded as if it was never sent. In this case that would
> > mean that the

I think that if we wait for a good request from the authentication server 
then the packet the authentication server is responding to is good in all 
respects.  Therefore it seems to me the cases are identical whether acting 
in pass through or not.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 21:26:45 -0800 (PST)

> respects.  Therefore it seems to me the cases are identical whether acting

Yes, I would agree.

---

From: [email-masked] (James Carlson)
Date: Thu, 13 Feb 2003 10:33:47 -0500

> that is of highly questionable value.

Exactly.

> in the haystack of attacking trash.

Right.

Should you want to fix this, I believe that you will need some way for
the EAP server (NAS) to perform the MIC itself.  Storing Response
messages and submitting them one at a time to the AAA server doesn't
work, since each one ends up being an individual Access-Request, it
necessarily facilitates the DoS attack by fobbing the load off onto
the centeralized server, and you have to suppose a very strange
implementation of the AAA server -- that server has to go into a mode
where it reissues the same Access-Challenge over and over, hoping that
a useful Access-Request in reply to the original Access-Challenge
eventually shows up.  Worse still, the EAP server is required to
buffer an arbitrary number of messages while it waits on the AAA
server, since there's perhaps a needle in that haystack somewhere.

I'm seeing no benefits for DoS protection from that path.  It looks to
me like it just gets worse the further one travels down it.

I can think of at least three ways to make the EAP server validation
of MICs happen: have the shared validation data used in the MIC be
agreed upon between the EAP server and the authenticatee alone
(leaving the authenticator out of the picture), have the protocol from
which the shared MIC-related validation data is derived structured
such that both the EAP server and the authenticator can derive the
correct data (and both perform MIC), or have the authenticator deliver
the validation data to the EAP server when MIC is first enabled.

The first of these three corresponds to pushing the MIC down to the
sub-EAP transport layer.  This seems quite fair to me, since the real
design fault (allowing injection) lies in the L2 in question, not in
EAP or its methods.

The second seems somewhat infeasible, since it means that the MIC
really ought to be part of the EAP framework itself, and that sounds
like a hazard.

The third seems promising, but will obviously require changes in that
2869bis draft.