Subject: [eap] Re: draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

From: Bernard Aboba <[email-masked]>
Date: Sun, 5 Dec 2004 10:23:55 -0800 (PST)

> Based on the source code comment about this, I seem to have noticed this
> first when testing against IAS. I did some quick testing with couple of
> RADIUS servers:
>
> FreeRADIUS: same Id
> Radiator: same Id
> Meetinghouse Aegis: lastId + 1
> Microsoft IAS: lastId + 1
>
> In other words, there are existing EAP authenticators that do not match
> the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt.
> RFC 2284 seemed to have the same text, so this is not even a new
> requirement.
>
> It looks like draft-ietf-eap-statemachine-05.txt is correct on this
> part. However, this is not going to help with the interoperability
> issue. I don't see any security issues with skipping this test and as
> such, I will leave the workaround in my implementation. Adding some kind
> of note about this issue in the draft could be useful, though.

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.

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

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 5 Dec 2004 12:09:40 -0800

> or Success messages, so it seems like there are some security

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.

> once the draft is published we will have more testing and some of these

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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 5 Dec 2004 21:38:53 -0800 (PST)

This sounds quite good to me.

Nick, other authors -- what do you think?

---

From: Nick Petroni <[email-masked]>
Date: Mon, 6 Dec 2004 15:34:24 -0500 (EST)

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