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

From: [email-masked] (Alper Yegin)
Date: Wed, 22 Jan 2003 14:33:34 -0800

> ------ Forwarded Message
> From: Bernard Aboba <[email-masked]>
> Date: Mon, 20 Jan 2003 22:59:56 -0800 (PST)
> To: Alper Yegin <[email-masked]>
> Cc: [email-masked], <[email-masked]>, <[email-masked]>
> Subject: Re: [eap] Re: preserving packet order in EAP
> 
> 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.

Obviously this is not a task that should be underestimated.

But there are few things that needs to be noted here.

The case 802.11i handles is the hardest case that PANA can be used for.
That is: using PANA in the absence of any lower layer security. Before that
case there are two other simpler ones. Namely, using PANA over physically
secure links (e.g., DSL), and over already secured link-layers (e.g.,
3GPP/3GPP2). One possible approach is to identify the common element among
all these scenarios and develop a modular solution set. Developing an EAP
carrier above IP seems to be the common denominator among these three. This
piece by itself should be sufficient to handle two of the cases, but not the
hardest one. 

The solution to first two cases can be developed first. For the last case,
there needs to be additional pieces in place (how to bind outcome of EAP,
keys, to subsequent data by using IPsec or L2 ciphers). But that should not
hold solving other cases back. As long as we keep an eye on the last case as
we develop the basic building block, we shall be fine.

alper

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 22 Jan 2003 14:01:20 -0800 (PST)

> 3GPP/3GPP2).

Yes, cases in which the link is physically secure are *much* simpler.

> One possible approach is to identify the common element among

Yes.

> we develop the basic building block, we shall be fine.

Yes. What I am suggesting is that there may be a need for an IP-layer
equivalent to the IEEE 802.11i 4-way handshake, to secure the "third leg".