Subject: [eap] Issue 97: Strict interpretation

From: [email-masked] (Bernard Aboba)
Date: Wed, 12 Mar 2003 13:04:53 -0800 (PST)

This was originally part of Issue 80, but it is now separated out into its
own issue to make discussion more manageable.

-------------------------------------------------------------------
Issue 97: Strict interpretation
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: March 7, 2003
Reference:
Document: EAP-01
Comment type: Technical
Priority: S
Section: 4.2.1
Rationale/Explanation of issue:
John Vollbrecht has proposed tightening of the EAP state
machine so as to preclude a number of possibilities,
including changing Type in the middle of a method, and
sending an EAP Success or Failure before a message is
complete.

As an alternative to that approach, a method-specific
notion of "strict interpretation" is offered here.

Proposed resolution (rewrite of Section 4.2.1):

"4.2.1 Strict Interpretation

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.

[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] 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: None of the methods defined in
this document support strict interpretation.
Authenticators operating in pass-through mode
cannot support "strict interpretation",
since this would require that the authenticator be
upgraded to support new methods."

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 13 Mar 2003 18:19:19 -0500

I

I like this except I suggest the following change to your implementation 
note

> cannot support "strict interpretation",

change the last phrase from

> upgraded to support new methods.

to

 since this would require the RADIUS or other backend protocol support that 
is not currently defined.