Subject: [eap] draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

From: Jouni Malinen <[email-masked]>
Date: Sat, 4 Dec 2004 09:28:26 -0800

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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Sat, 4 Dec 2004 19:59:10 -0500 (EST)

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.

---

From: Jouni Malinen <[email-masked]>
Date: Sat, 4 Dec 2004 18:43:31 -0800

> this was true for FreeRadius at the time, I assume it still is.

I implemented the peer statemachine first with the verification. After
finding out that this does not interoperate with many RADIUS servers, I
had to remove this verification.. In other words, I cannot implement the
current statemachine draft as-is without causing major interoperability
issues.

Based on the source code comment about this, I seem to have noticed this
first when testing against IAS. I did some quick testing with couple of
RADIUS servers:

FreeRADIUS: same Id
Radiator: same Id
Meetinghouse Aegis: lastId + 1
Microsoft IAS: lastId + 1

> least one other thing that will break in the diagrams if this statement is

Section 4.1 is about Requests and Responses, it does not cover
EAP-Success. However, now that I looked again more closely, there is
actually text in section 4.2 that seems to cover this:

   Identifier

      The Identifier field is one octet and aids in matching replies to
      Responses.  The Identifier field MUST match the Identifier field
      of the Response packet that it is sent in response to.

(this is for Success and Failure)

In other words, there are existing EAP authenticators that do not match
the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt.
RFC 2284 seemed to have the same text, so this is not even a new
requirement.

It looks like draft-ietf-eap-statemachine-05.txt is correct on this
part. However, this is not going to help with the interoperability
issue.. I don't see any security issues with skipping this test and as
such, I will leave the workaround in my implementation. Adding some kind
of note about this issue in the draft could be useful, though.