eap Mailing List: Re: draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

[Nick Petroni (npetroni]

Jouni,

This question revisits one from November 2003. The original diagrams did
not include it, but Joe Salowey (correctly, I think) pointed out that this
check was missing from the Peer diagram. Here is Joe's original mail:

http://mail.frascone.com/pipermail/public/eap/2003-November/001869.html

Take a look at his fifth point. There were a couple of follow-up threads,
the most notable here:

http://mail.frascone.com/pipermail/eap/2003-December/001987.html
http://mail.frascone.com/pipermail/eap/2003-December/001993.html
http://mail.frascone.com/pipermail/eap/2003-December/001998.html
http://mail.frascone.com/pipermail/eap/2003-December/002004.html

I remember running to my set of sniffs and for the first time realizing
the Success identifier was the same as the last Response identifier. I know
this was true for FreeRadius at the time, I assume it still is.

Finally, from RFC3748 here is some text from section 4.1. Note that it
says that the identifier is changed on *new Requests* and should match the
value of "the currently outstanding Request". If implementations do not
work this way, we will need to revisit this conversation. I know of at
least one other thing that will break in the diagrams if this statement is
removed.

Thanks,
nick

   Identifier

      The Identifier field is one octet.  The Identifier field MUST be
      the same if a Request packet is retransmitted due to a timeout
      while waiting for a Response.  Any new (non-retransmission)
      Requests MUST modify the Identifier field.

      The Identifier field of the Response MUST match that of the
      currently outstanding Request.  An authenticator receiving a
      Response whose Identifier value does not match that of the
      currently outstanding Request MUST silently discard the Response.

      In order to avoid confusion between new Requests and
      retransmissions, the Identifier value chosen for each new Request
      need only be different from the previous Request, but need not be
      unique within the conversation.  One way to achieve this is to
      start the Identifier at an initial value and increment it for each
      new Request.  Initializing the first Identifier with a random
      number rather than starting from zero is recommended, since it
      makes sequence attacks somewhat more difficult.


On Sat, 4 Dec 2004, Jouni Malinen wrote:

> The Peer State Machine in draft-ietf-eap-statemachine-05.txt requires
> that reqId == lastId when processing EAP-Success packet. However, I do
> not see such requirement in RFC 3748. In addition, most (if not all)
> existing RADIUS servers seem to implement EAP in a way that Identifier
> in EAP-Success is actually incremented by one from the last EAP-Request.
>
> draft-ietf-eap-statemachine-05.txt state machines for EAP authenticator
> are indeed not incrementing Identifier for EAP-Success, but again, this
> is not specified in RFC 3748. The only requirement for Identifier in
> RFC 3748 seems to be that each EAP-Request is sent with different
> Identifier than the previous EAP-Request. As far as I can tell, this
> leaves it open to the implementation to decide which Identifier is used
> in EAP-Success.
>
> Should the (reqId == lastId) requirement be removed from the peer state
> machine?
>
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>