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

[Nick Petroni (npetroni]

I also like this fix. Section 8, "Implementation Considerations" would be
another possible place for this text, but since it only pertains to the
Peer maybe Section 4 is best.

Thanks,
nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

On Sun, 5 Dec 2004, Bernard Aboba wrote:

> 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
> >
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>