Subject: RE: [eap] PANA and EAP keying framework

From: "Walker, Jesse" <[email-masked]>
Date: Tue, 10 Jan 2006 12:59:33 -0800

There are numerous places, but you can start with clause 5.9.2.1, which
gives an expository overview of the process.

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2006 12:47 PM
> To: Walker, Jesse
> Cc: Yoshihiro Ohba; Bernard Aboba; [email-masked]
> Subject: Re: [eap] PANA and EAP keying framework
> 
> Jesse,
> 
> On Tue, Jan 10, 2006 at 12:30:58PM -0800, Walker, Jesse wrote:
> > Yoshihiro
> >
> > > I don't think 802.11i prohibits any IP traffic to pass throuth
> > > uncontrolled port before 4-way handshake.  In fact, there is a
> > > description in section 5.4.2.2 of IEEE 802.11i 2004 specification:
> > [Walker, Jesse] This is not true. 802.1X frames are the only type of
> > data 802.11i allows to pass over the link prior to key confirmation.
IP
> > traffic is not encapsulated with the 802.1X Ethertype, so is
expressly
> > blocked.
> 
> Can you point out which text in the 802.11i specification states this
> specific behavior?  How can we interpret the quoted text in section
> 5.4.2.2?
> 
> In any case, another way is to use multiple (virtual) APs, one
> operating in 'open' authentication running PANA and the other
> operating in 802.11i, and switching from the former AP to the latter
> after PANA authentication.
> 
> Regards,
> Yoshihiro Ohba
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 10 Jan 2006 13:05:01 -0800

>IP traffic is not encapsulated with the 802.1X Ethertype, so is
>expressly blocked.

Right.

>after PANA authentication.

That is also forbidden in IEEE 802.11i, which includes the authorizations as 
part of the PMKSA context.  Therefore it is not permitted to use 
authorizations provided for one virtual AP with another virtual AP.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jan 2006 16:27:39 -0500

> gives an expository overview of the process.

This partially answers to my questions, but I think the 802.11i
specification is vague about the behavior you mentioned.

For example, in the following text in clause 5.9.2.1:

"
Upon successful completion of the 4-Way Handshake, the Authenticator
and Supplicant have authenticated each other; and the IEEE 802.1X
Controlled Ports are unblocked to permit general data traffic.
"

- What is the definition of "general data traffic"?

- The above text does not say anything about whether any data frame
other than 802.1X messages is not allowed to pass through uncontrolled
port.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Jan 2006 16:44:32 -0500

On Tue, Jan 10, 2006 at 01:05:01PM -0800, Bernard Aboba wrote:
> That is also forbidden in IEEE 802.11i, which includes the authorizations 
> as part of the PMKSA context.  Therefore it is not permitted to use 

The authorization provided for the 'open' authentication AP is given
free regardless of the PANA authentication result (the authoriation
for this AP is given even before starting PANA authentication).  On
the other hand, the authorization provided for other APs are given
only after successful PANA authentication.  So I don't understand what
is the issue here.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 10 Jan 2006 18:29:01 -0500

Hello Jesse

Only a short question for clarification. As Yoshi has commented in 
section 5.4.2.2 in 802.11i we can find:

" 
IEEE 802.1X Supplicants and Authenticators exchange
protocol information via the IEEE 802.1X Uncontrolled Port. It is
expected that most other protocol exchanges will make use of the IEEE
802.1X Controlled Ports. However, a given protocol may need to bypass
the authorization function and make use of the IEEE 802.1X
Uncontrolled Port.
"

Then when we read 

"However, a given protocol may need to bypass
the authorization function and make use of the IEEE 802.1X
Uncontrolled Port."
 
we should understand "a given protocol" as only 802.1X frames , right?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------