Subject: [eap] Proposed resolution of Issue 80

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 11:03:39 -0800 (PST)

Replace section 4.2.1 with the following:

"4.2.1 Strict Interpretation

In order to decrease vulnerability to spoofing of EAP packets,
including Success and Failure packets, EAP methods MAY indicate
within their specification that they follow a "strict interpretation"
from the point where an initial Request is answered with a
Response of the same Type, until the method completes.

An EAP method making use of "strict interpretation" MUST
include a definition of completion for both the peer
and authenticator, and also MUST indicate the conditions
under which an EAP Failure or Success are accepted, and
when they should be silently discarded.

Methods supporting "strict interpretation" behave as follows:

[a] On the peer, all EAP packets are silently discarded, except
for those with Code=1 (Request) and Type=EAP-Method-Type. Methods
supporting "strict interpretation" therefore MUST NOT support
Identity requery or Notification.

[b] On the authentication server (pass-through) or
authenticator (non-pass-through), all EAP packets are
silently discarded, except those with Code=2 (Response)
and Type=EAP-Method-Type. Methods supporting "strict
interpretation" MUST NOT send send a Nak (legacy or
expanded) in reply to a Request, after an initial
non-Nak Response has been sent.

Note that authenticators operating in pass-through mode
MUST NOT support "strict interpretation", since this
would require method-specific knowledge."

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 06 Mar 2003 21:34:05 -0500

I think this is fine, except for the last paragraph about pass thru 
authenticators, which I think should be deleted.  Pass thru authenticators 
can act in the same way as you described in the first paragraphs - if 
RADIUS is the backend protocol then there would be changes to RADIUS to 
support it, but it could be done.  Protocols other than RADIUS could do it 
in the future.  I think this paragraph is best left to the EAP/RADIUS doc.

John

--On Thursday, March 6, 2003 11:03 AM -0800 Bernard Aboba 
<[email-masked]> wrote:

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

---

From: [email-masked] (Jari Arkko)
Date: Fri, 07 Mar 2003 08:21:53 +0200

John Vollbrecht wrote:
> authenticators, which I think should be deleted.  Pass thru 
> authenticators can act in the same way as you described in the first 
> paragraphs - if RADIUS is the backend protocol then there would be 
> changes to RADIUS to support it, but it could be done.  Protocols other 
> than RADIUS could do it in the future.  I think this paragraph is best 
> left to the EAP/RADIUS doc.

For what its worth, I think the statement adds value, because it
points out a limitation in how the strict mode can be implemented.
However, I do agree with you that we shouldn't be putting in keywords for
these cases. I would suggest a compromise: s/MUST NOT/typically can
not/. Would that work for you?

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 21:27:31 -0800 (PST)

> in the future.  I think this paragraph is best left to the EAP/RADIUS doc.

The problem is that in practice, authenticator implementations do not act
this way -- and changing the spec to create "flexibility" would cause
interoperability problems.

---

From: [email-masked] (Nick Petroni)
Date: Fri, 7 Mar 2003 01:47:36 -0500 (EST)

> interoperability problems.
I don't understand why one would do this at all if it doesn't work in pass
through. My understanding of the reason is to avoid DoS or other problems
that occur from invalid packet injection. I would think almost any method
implemented in non-passthrough would basically be extremely simple and not
have the problem of getting additional requests in the middle of it
anyway. Am I missing something?

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 21:40:36 -0800 (PST)

> anyway. Am I missing something?

The issue is that in pass-through authenticators keep very little state
(the Identifier). They do not look at the Type and make sure they match.

That's actually a *good* thing -- if they check Type codes, then we
wouldn't have the ability to introduce expanded Nak, for example.

So if you're going to do that kind of thing, it needs to be done on the
authentication server or the peer. Authenticators are largely forwarding
engines.

---

From: [email-masked] (Nick Petroni)
Date: Fri, 7 Mar 2003 02:02:03 -0500 (EST)

ok, sorry I misread. It doesn't say it doesn't work in pass-through, it
says AUTHENTICATORS don't do it in pass through, but rather the
authentication server handles this. My bad.

nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 21:51:59 -0800 (PST)

I should also add that "strict interpretation" as it is proposed here is
method-specific. That is, some methods may not require it, and others may.
That means that a pass-through authenticator attempting to implement it
would need method-specific knowledge -- it couldn't act the same way for
each method. That's what makes it particularly hard to think of
implementing this on a pass-through authenticator.

Note that alternative approaches have been proposed that would work for
*all* EAP methods. From some perspectives that approach could be said to
be more consistent. But the complaint was that it would impose an extra
round-trip on protocols such as EAP SIM, so that they could terminate
"normally".

As with everything else, we've got to find the balance between:

a. Backward compatibility.
b. Simplicity.
c. Security.
d. Existing and future EAP methods.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 6 Mar 2003 22:03:39 -0800 (PST)

> not/. Would that work for you?

We can certainly change the text to incorporate this (as below). But I
think the bigger question is whether the "strict interpretation" advocated
in this proposed resolution is the right way to go.

In practice, my understanding is that some EAP methods do implement
filters similar to the ones described here. On the other hand, some of the
filtering (for Success/Failure in the middle, for example) is handled in
the EAP layer. And of course, there are some implementations that do
nothing. So the existing practice is all over the place.

In addition to being somewhat complex, this proposed resolution really
doesn't provide any guaranteed security properties -- it's all up to the method.
That makes it hard to test an EAP implementation for compliance, particularly since the
specs of existing EAP methods don't include any mention of "strict
interpretation".

--------------------------------------------------------------------------
Proposed resolution (rewrite of Section 4.2.1):

[b] On the authentication server (pass-through) or
authenticator (non-pass-through), all EAP packets are
silently discarded, except those with Code=2 (Response)
and Type=EAP-Method-Type.

[c] Peer methods supporting "strict
interpretation" MUST NOT send a Nak (legacy or
expanded) in reply to a Request, after an initial
non-Nak Response has been sent.

Note that authenticators operating in pass-through mode
typically cannot support "strict interpretation", since this
would require method-specific knowledge."

---

From: [email-masked] (John Vollbrecht)
Date: Fri, 07 Mar 2003 02:40:33 -0500

> not/. Would that work for you?
sure

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Mar 2003 05:02:56 -0800 (PST)

Is this more clear?

In order to decrease vulnerability to spoofing of EAP packets,
including Success packets, EAP methods MAY indicate
within their specification that they follow a
"strict interpretation" of EAP.

When requested by a method, "strict interpretation"
causes the EAP implementation to impose inbound filter
rules from the point where an initial Request is
answered with a Response of the same Type, until
the method completes. "Strict interpretation" also
implies that on completion the peer method will
indicate whether it succeeded (was able to
authenticate the authenticator) or failed (did
not succeed in authenticating the authenticator).
Unsuccessful method completion results in
termination of EAP authentication and silent
discard of EAP Success packets.

An EAP method making use of "strict interpretation" MUST
include a definition of completion for both the peer
and authenticator, and also MUST indicate the conditions
under which successful completion will be indicated.

The filter rules are as follows:

[a] On the peer, all EAP packets are silently discarded, except
for those with Code=1 (Request) and Type=EAP-Method-Type.
Therefore when "strict interpretation" is in effect,
Identity requery or Notification cannot be supported.

[c] When "strict interpretation" is in effect, a peer MUST NOT
send a Nak (legacy or expanded) in reply to a Request, after
an initial non-Nak Response has been sent.

Implementation note: Authenticators operating in
pass-through mode cannot support "strict interpretation",
since this would require that the authenticator be
upgraded to support new methods."