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

From: Alper Yegin <[email-masked]>
Date: Wed, 22 Jan 2003 13:50:17 -0800

There are few more e-mails that escaped the mailing list. Let me forward
them here... This problem should be fixed, hopefully no more forwards are
necessary after these few..

alper

------ Forwarded Message
From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jan 2003 22:52:19 -0800 (PST)
To: Alper Yegin <[email-masked]>
Cc: [email-masked], <[email-masked]>
Subject: Re: [eap] Re: preserving packet order in EAP

> > 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?

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

> > Yes, those transports would be fine, providing that they provide the
> > 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.

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.

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

------ End of Forwarded Message

---

From: Alper Yegin <[email-masked]>
Date: Wed, 22 Jan 2003 14:01:02 -0800

> preserved ordering, yes that would work.

Yes, that's one possibility.

> you might have used EAP for authentication -- but security has not been

Definitely agreed. My point was, regardless of whether EAP was carried
over UDP, or ICMP, or TCP, I suspect this tying of key to subsequent data
would happen the same way.

> does not make any recommendations in that department, then that is also a

Agreed.

alper