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

[Jouni Malinen (jkmaline]

On Sat, Dec 04, 2004 at 07:59:10PM -0500, Nick Petroni wrote:

> 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.

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

> 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.

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.

-- 
Jouni Malinen                                            PGP id EFC895FA