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

[Pasi.Eronen (Pasi.Eronen]

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