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

[Jouni Malinen (jkmaline]

On Sun, Dec 05, 2004 at 10:23:55AM -0800, Bernard Aboba wrote:

> I'd be ok with a note, but since this is a MUST in RFC 3748, the note
> shouldn't imply that existing behavior is correct.  Not requiring an
> Identifier match does make it somewhat easier to spoof EAP-Failure
> or Success messages, so it seems like there are some security
> implications.

OK. In order to limit the effect, the workaround could be changed to be
(reqId == lastId) || (reqId == (lastId + 1) & 0xff) which seems to cover
all the EAP implementations I have seen in RADIUS authentication
servers. This would at least skip some of the randomly selected Id
values.

I did not see a good place for such a note in the draft. Maybe a new
section with something like this would be ok:

4.6 Peer state machine interoperability with deployed implementations

Number of deployed EAP authenticator implementations, mainly in RADIUS
authentication servers, have been observed to incorrectly increments
Identifier field when generating EAP-Success and EAP-Failure packets
which is against the MUST requirement in RFC 3748 section 4.2. The peer
state machine is based on RFC 3748 and as such it will discard such
EAP-Success and EAP-Failure packets.

As a workaround for the potential interoperability issue with existing
implementations, conditions for peer state machine transitions from
RECEIVED state to SUCCESS and FAILURE states MAY be changed from
(reqId == lastId) to ((reqId == lastId) || (reqId == (lastId + 1) &
0xff)). However, since this behavior does not conform with RFC 3748,
such a workaround is not recommended and if included, it should be
implemented as an optional workaround that can be disabled.


> One of the reasons for completing work on RFC 3748 and the State Machine
> document was to enable the development of conformance tests.  Hopefully
> once the draft is published we will have more testing and some of these
> issues will be resolved.

Keeping this in mind, I'll make the workaround configurable.. This
allows strict standard conformance mode to be enabled when desired while
still allowing the default behavior to interoperate with most existing
implementations. I think I have already had to make ten or so
workarounds for EAP related interop issues, so getting more conformance
testing sounds like a good idea ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA