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

[Bernard Aboba (aboba]

This sounds quite good to me.

Nick, other authors -- what do you think?

On Sun, 5 Dec 2004, Jouni Malinen wrote:

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