Subject: [eap] Re: preserving packet order in EAP

From: [email-masked] (Bernard Aboba)
Date: Mon, 20 Jan 2003 12:46:19 -0800 (PST)

On Monday, January 20, 2003 Dan Forsberg wrote:

> EAP requires that packet order is maintained by the lower layer. My
> concern is that EAP can't be carried by UDP or IP alone, because these
> protocols do not preserve the packet order?

Those transports are illegal, because they don't preserve order, correct.

> TCP/SCTP would be another option to carry EAP, but EAP detects
> duplicates and does re-transmissions already.

Yes, those transports would be fine, providing that they provide the
appropriate security -- namely per-packet integrity and authentication.

> Another comment/question:
> Isn't EAP request-response style protocol, so what are the
> possibilites/consequences for packet order mismatch?

The issue comes up since RFC 2284 doesn't require the Identifier space to
be monotonically increasing. That means that if a Request packet with ID 1
were retransmitted, and arrived *after* a Request packet with ID 2, it
could be erroneously thought by the peer to represent a new Request,
rather than a retransmission.

> One possible solution for this problem is to require the Authenticatee to remember
> the ID numbers inside the EAP method (message id's between the initial
> request and  Success/Failure msgs). This would imply that no EAP method
> should produce more than 256 requests per authentication.

That would be incompatible with existing implementations, would
impact re-authentication and would enable new DoS attacks.

> Another solution to this problem is to prohibit simultaneous *same type* of
> authentications.

Again, that is incompatible with existing implementations, which can
authenticate multiple users at a time.

---

From: [email-masked] (Alper Yegin)
Date: Mon, 20 Jan 2003 23:14:05 -0800

> Those transports are illegal, because they don't preserve order, correct.

If UDP or ICMP is used as transport, couldn't an identifier field
in the PANA header be a solution to this problem?

> appropriate security -- namely per-packet integrity and authentication.

Assuming we are talking about per-(data-)packet integrity and authentication
after the initial authentication, how is this related to the EAP
transport? Regardless of the EAP transport, that protection should
be provided by physical, link-layer or network-layer mechanisms.

alper

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 20 Jan 2003 22:52:19 -0800 (PST)

> in the PANA header be a solution to this problem?

If you're saying that PANA would define its own transport over UDP that
preserved ordering, yes that would work.

> be provided by physical, link-layer or network-layer mechanisms.

It is related because otherwise you have not tied the key that is derived
in EAP to subsequent data and you have a vulnerability to hijacking. So
you might have used EAP for authentication -- but security has not been
achieved.

There are also issues relating to protection of the EAP exchange itself.
Those can presumably be solved by choice of method -- but if PANA also
does not make any recommendations in that department, then that is also a
vulnerability.

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 20 Jan 2003 22:59:56 -0800 (PST)

Overall, it is important to understand that PANA (and IEEE 802.11i for
that matter) represent very major extensions to the existing EAP usage
model. RFC 2284 was created with the assumption that the underlying
physical medium was secure, as was IEEE 802.1X (which was created for use
with wired networks only).  Where EAP is run over wireless that is not the
case. This greatly expands the potential security vulnerabilities.

IEEE 802.11i has put in substantial effort to address these issues:
addition of a "third leg" of mutual auth and key derivation
between the NAS and client; proper key wrapping between the AAA server and
NAS; definition of the key hierarchy, both for individual sessions, and
for fast handoff; support for pre-authentication; EAP method requirements.

To get an idea of what you're up against, I would suggest a careful
reading of IEEE 802.11i.