eap Mailing List: Issue 251: immediate success/failure

[Jari Arkko (jari.arkko]

> I did not find a place in RFC 3748 saying that it is forbidden to have 
> multiple round trips of the Identity method.

Right. Its not. Here's what Section 2.1 says, with my
emphasis added:

   An EAP conversation *MAY utilize a sequence* of methods.  A common
   example of this is an Identity request followed by a single EAP
   authentication method such as an MD5-Challenge.  However, the peer
   and authenticator MUST utilize *only one authentication method (Type 4
   or greater)* within an EAP conversation, after which the authenticator
   MUST send a Success or Failure packet.

> If this is the case, the state machine reflects this... sadly, this 
> leads to an unnecessary (& stupid & not dramatic) DoS attack: the 
> attacker keeps sending EAP Identity request and the peer may keep 
> replying to these requests (and discarding the valid requests of the 
> server).

This is true. I think this is covered by your security
considerations text.

> [Nick Petroni]
>
> I don't see the RFC as denying the use of immediate failure. The 
> behavior is valid IMHO. 

Immediate Success is of course forbidden.

Reading RFC 3748 Section 2 bullets [1] and [4], and
Section 4.2 first paragraph, the spec seems to say
that immediate Failure is also forbidden. There
is strictly speaking no keyword that prohibits it, but
the text always indicates that you must have a
method in progress before you can send a Failure.
See this text from Section 4.2:

  "If the authenticator cannot authenticate the peer
   (unacceptable Responses to one or more Requests), then
   after unsuccessful completion of the EAP method in
   progress, the implementation MUST transmit an EAP
   packet with the Code field set to 4 (Failure)."

(You could perhaps debate if the part in paranthesis,
is a part of the normative text and exhaustive.)

> [Florent]
>
> To be honest, I started the mail you replied to by lamenting that this 
> was not mandated by EAP (which you tend to think) but after rereading 
> RFC 3748 (I stumbled across some wording like "The EAP authentication 
> exchange proceeds as follows: [1] The authenticator sends a Request to 
> authenticate the peer." RFC 3748 page 7).
>
> So, although it didn't seem like very normative text, I changed my mind 
> and now think that EAP mandates that a dialog begins with a request.
>
> I'd really like others' opinion on this, Bernard, Jari?

I think you are correct.

What do others think?

If this is correct, then it may be that the state machine
needs some modification. Or so I would expect, if Nick this
this behaviour is allowed. OTOH, when I read -04 peer state
machine, one of the required conditions to go into the FAILURE
state is to have reqId == lastId. Since lastId has been initialized
to NONE, it seems that an immediate Failure is not accepted
by the current state machine.

--Jari