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

[Jari Arkko (jari.arkko]

I think the suggested text looks fine.

The state of the document is that we have revised it,
but it has not yet been re-reviewed by IESG, so I think
we can fix this issue, and let Margaret know that there's
a new document revision. When can you post a new revision?

--Jari

Pasi.Eronen [at] nokia.com wrote:
> I don't particularly like the idea of revising the document
> again (it was already once in the RFC editor queue...), 
> especially since this is really a fix to RFC3748, not
> just the state machine document.
>
> (The implementation note itself looks ok, though, and if we 
> do decide to include it here, Section 8 would probably be 
> the right place.)
>
> BR,
> Pasi
>
>
> > -----Original Message-----
> > From: Nick Petroni
> > Sent: Monday, December 06, 2004 10:34 PM
> > To: eap [at] frascone.com
> > Subject: Re: [eap] Re: draft-ietf-eap-statemachine-05.txt and 
> > Identifier in EAP-Success
> >
> >
> > 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                                            
>
>
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap