Subject: RE: [Pana] Correction to pana-fwk section 10.2.3

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Jan 2006 23:42:24 +0200

Rafa,

Never mind my earlier comment. I think I understand the issue a bit better.

First of all, I think we should look at the classification from
"client/network authentication" perspective. If we want to include PSK with
static keys, then we have:

a- Unauthenticated (free) networks
b- PANA-authenticated networks
c- PSK-authenticated networks
d- IEEE 802.1X-authenticated networks

(a) is recognized as it announces neither IEEE 802.1X-EAP nor PSK modes.
(d) is recognized as it announces both.

(b) and (c) only announce the PSK mode. But, if the client attempts to gain
access to the (c) and does not hold the statically-configured key, it'll
fail. That is how a (c) type will appear to a PANA client that does not hold
a statically configured PSK with the network.

Does this make sense?

Alper

> -----Original Message-----
> From: Rafa Marin Lopez [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2006 6:55 AM
> To: Alper Yegin; [email-masked]
> Cc: 'Yoshihiro Ohba'; Rafa Marin Lopez
> Subject: Re: [Pana] Correction to pana-fwk section 10.2.3
> 
> Hi Alper...
> 
> Alper Yegin wrote:
> 
> >Hi Rafa,
> >
> >You said:
> >
> >
> >
> >>However this is not true becuase PaC can distinguish between type a) and
> >>type b) basically
> >>becuase type a) network does NOT announce RSN IE in beacon frame/probe
> >>response and type b) DOES (PSK mode).
> >>
> >>
> >
> >Does it have to be that way? Can't we design it such that for Type B RSN
> IE
> >does not announce PSK mode?
> >
> To understand:
> 
> ... are you saying not to include RSN IE?
> 
> or include RSN IE without AKM suite?
> 
> or establishing a new Suite Type  in AKM suite ?
> 
> 
> if RSN IE does not announce PSK mode... what kind of mode you have in mind
> to announce?.
> 
> 
> >I think this would keep things simpler.
> >
> >Alper
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >>Rafa Marin Lopez
> >>Sent: Friday, December 30, 2005 5:12 PM
> >>To: [email-masked]
> >>Cc: Yoshihiro Ohba; Rafa Marin Lopez
> >>Subject: [Pana] Correction to pana-fwk section 10.2.3
> >>
> >>In section 10.2.3 three types of network are explained
> >>
> >>"
> >>a) Free access network
> >>
> >>     There is no IEEE 802.1X or PANA authentication in this access
> >>     network.
> >>
> >>b) PANA-secured network
> >>
> >>     There is PANA authentication in this access network.
> >>
> >>c) IEEE 802.1X-secured network
> >>
> >>     There is IEEE 802.1X authentication in this access network.
> >>"
> >>Considering that classification,  it is said also in this section:
> >>
> >>"Types (a) and (b) are not distinguishable until the PaC associates with
> >>the AP ".
> >>
> >>However this is not true becuase PaC can distinguish between type a) and
> >>type b) basically
> >>becuase type a) network does NOT announce RSN IE in beacon frame/probe
> >>response and type b) DOES (PSK mode).
> >>
> >>Actually PaC cannot distinguish between networks where PANA is used to
> >>bootstrap PSK  and network where PSK is required
> >>but it is statically configured. In both cases RSN IE announces PSK mode
> >>in RSN IE.
> >>
> >>Another thing that could not be clear in the classification is the
> >>meaning of IEEE 802.1X-secured network. Are we assuming here both IEEE
> >>802.1X authentication with EAP or PSK should be also included here?. My
> >>understanding of type c) network is EAP authentication is used but no
> >>PSK mode is considered.
> >>
> >>But in any case, even if PSK mode is also included  in type c)
> >>
> >>c) IEEE 802.1X-secured networks
> >>      c1) PSK authentication
> >>      c2) EAP authentication
> >>
> >>then i would say PaC cannot distinguish between type b) networks and
> >>type c1) networks and not between type a) and type b) . If PSK
> >>authentication is not included in type c) networks then classification
> >>is incomplete , we should add networks that requires a PSK and no PANA
> >>authentication is possible.
> >>
> >>
> >>
> >>Thus I think the section 10.2.3 could be rewritten more clearly in this
> >>way:
> >>
> >>"
> >>10.2.3  Capability Discovery
> >>
> >>  When a PaC is a mobile, there may be multiple APs available in its
> >>  vicinity.  Each AP are connected to one of the following types of
> >>  access networks.
> >>
> >>
> >>  a) Access network without link-layer security
> >>
> >>   There is no IEEE 802.11i link-layer security in this access network.
> >>
> >>
> >>  b) Access network with link-layer security
> >>
> >>     In this case two options are considered to enable link-layer
> >>      security:
> >>
> >>     b1.  Access network operating in IEEE 802.1X/EAP mode
> >>
> >>         There is IEEE 802.1X and EAP authentication in this access
> >>         network.
> >>
> >>     b2.  Access network operating in PSK mode
> >>
> >>          An IEEE 802.11i pre-shared key is used for authentication.
> >>There
> >>       are two alternatives:
> >>
> >>          b21.  Dynamically configured PSK
> >>
> >>            There is PANA authentication in this access network which
> >>            allows the PaC to bootstrap a PSK to access the current AP.
> >>
> >>
> >>          b22.  Statically configured PSK
> >>
> >>
> >>            There is no PANA authentication.  To access this network AP
> >>            and PaC must share a statically configured PSK to access the
> >>            network.
> >>
> >>  PaC can distinguish between Type (a) and Type (b) networks
> >>  by checking the capability information advertised in
> >>  IEEE 802.11 Beacon/Probe Response frames (IEEE 802.11i defines
> >>  RSN Information Element (IE) for this purpose).
> >>
> >>  Specifically if no RSN IE is contained in Beacon and Probe
> >>  Response frames then the access network is Type (a), otherwise it is
> >>  Type (b).
> >>
> >>  Type (b1) and Type (b2) can be recognized by checking the contents of
> >>  the RSN IE, i.e., if IEEE 802.1X-EAP mode is advertised in the RSN IE
> >>  the access network is Type (b1), otherwise if PSK mode is adverstised
> >>  it is Type (b2).
> >>
> >>  Since the RSN IE does not give further information to distinguish Type
> >>  (b21) from Type (b22), the PaC needs to take an additional action of
> >>  associating to the AP, acquiring an IP address and engaging in
> >>  (solicited or unsolicited) PAA discovery.
> >>
> >>
> >>  If the PaC receives a PANA message from a PAA, then the access network
> >>  is Type (b21), otherwise, it is type (b22).
> >>
> >>  The PaC behavior after identifying an access network type is
> >>  described in Section 10.2, Section 10.2.1 and Section 10.2.2. "
> >>
> >>Regards.
> >>
> >>--
> >>------------------------------------------------------
> >>Rafael Marin Lopez
> >>Faculty of Computer Science-University of Murcia
> >>30071 Murcia - Spain
> >>Telf: +34968367645    e-mail: [email-masked]
> >>------------------------------------------------------
> >>
> >>
> >>_______________________________________________
> >>Pana mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/pana
> >>
> >>
> >
> >
> >
> >
> >
> 
> 
> --
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645    e-mail: [email-masked]
> ------------------------------------------------------

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Jan 2006 11:08:57 -0500

Hi Alper ... sorry for the delayed answer...

>(a) is recognized as it announces neither IEEE 802.1X-EAP nor PSK modes.
correct

>(d) is recognized as it announces both.
here , only IEEE 802.1X/EAP is announced but not PSK mode. Thus it is 
easily recognizable

>(b) and (c) only announce the PSK mode.
>
correct

> But, if the client attempts to gain
>fail.
correct

> That is how a (c) type will appear to a PANA client that does not hold
If PaC has not a configured PSK, the option for PaC  is try to see if 
the AP belongs to type (b). If PaC cannot configure IP (i.e. DHCP fails) 
or it does not receive PSR message the PaC should consider network as 
type (c) and thus inaccesible becuase it has not a PSK for that AP.

>Does this make sense?
Do you prefer to categorize networks with these 4 options?

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 Jan 2006 23:26:07 +0200

Hi Rafa,

> type (c) and thus inaccesible becuase it has not a PSK for that AP.

If the network is type (c), wouldn't it try to force the client to 4-way
handshake? This should come before a DHCP or PANA attempt. So, if the client
is subject to 4-way handshake, then we can conclude this is a type (c)
network.

> Do you prefer to categorize networks with these 4 options?

This categorization focuses on the client/network authentication protocol.
(as opposed to L2 per-packet security, which can be enabled via PANA or
802.1X). For that, I think it fits this document better.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Jan 2006 16:36:33 -0500

> is subject to 4-way handshake, then we can conclude this is a type (c)

Or the AP may Disassociate the client without running 4-way handshake
immediately when it fails to find a PSK for the client.

> 802.1X). For that, I think it fits this document better.

I agree.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Jan 2006 19:17:04 -0500

Hi Yoshi, Alper

>immediately when it fails to find a PSK for the client.
Yes these both cases are possible. If APs has not PSK for that PaC AP
would disassociate the client becuase it does not find any key for that
STA. If AP has PSK will try to run 4-way handshake with that key just
after association.

Considering this, PaC may detect type (c) network inmediately if it is
disassociated or 4-way handshake is started just after association.

Thus (apart from the new classification you propose which I agree with)
we should now say something like:

Since the RSN IE does not give further information to distinguish Type
(b) from Type (c),
the PaC needs to take an additional action of trying to associate to the
AP.
If PaC receives a disassociation frame from AP or AP starts inmediately
4-way handshake after association,
PaC can consider network as type (c).

Now "acquiring an IP address and engaging in (solicited or unsolicited)
PAA discovery." does not look needed anymore.

is this ok for you?

>I agree.
I also agree with the new categorization. I am going to send a modified
text following the new one.

>>>>>>>However this is not true becuase PaC can distinguish between type a)
>>>>>>>              
>>>>>>>
>>>and
>>>      
>>>
>>>>>>>type b) basically
>>>>>>Does it have to be that way? Can't we design it such that for Type B
>>>>>>            
>>>>>>
>>>RSN
>>>      
>>>
>>>>>>            
>>>>>>
>>>>>IE
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>if RSN IE does not announce PSK mode... what kind of mode you have in
>>>>>          
>>>>>
>>>mind
>>>      
>>>
>>>>>to announce?.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>>>              
>>>>>>>
>>>Of
>>>      
>>>
>>>>>>>Rafa Marin Lopez
>>>>>>>"Types (a) and (b) are not distinguishable until the PaC associates
>>>>>>>              
>>>>>>>
>>>with
>>>      
>>>
>>>>>>>the AP ".
>>>>>>>
>>>>>>>However this is not true becuase PaC can distinguish between type a)
>>>>>>>              
>>>>>>>
>>>and
>>>      
>>>
>>>>>>>type b) basically
>>>>>>>but it is statically configured. In both cases RSN IE announces PSK
>>>>>>>              
>>>>>>>
>>>mode
>>>      
>>>
>>>>>>>in RSN IE.
>>>>>>>
>>>>>>>802.1X authentication with EAP or PSK should be also included here?.
>>>>>>>              
>>>>>>>
>>>My
>>>      
>>>
>>>>>>>Thus I think the section 10.2.3 could be rewritten more clearly in
>>>>>>>              
>>>>>>>
>>>this
>>>      
>>>
>>>>>>>way:
>>>>>>>
>>>>>>>"
>>>>>>>          and PaC must share a statically configured PSK to access
>>>>>>>              
>>>>>>>
>>>the
>>>      
>>>
>>>>>>>          network.
>>>>>>>
>>>>>>>Since the RSN IE does not give further information to distinguish
>>>>>>>              
>>>>>>>
>>>Type
>>>      
>>>
>>>>>>>If the PaC receives a PANA message from a PAA, then the access
>>>>>>>              
>>>>>>>
>>>network
>>>      
>>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Jan 2006 19:24:52 -0500

OK.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Jan 2006 23:25:16 -0500

Considering last discussions, here you can find the new text for section
10.2.3,
let me know if it is ok for you.

"

a) Unauthenticated (free) networks

b) PANA-authenticated networks

There is PANA authentication in this access network which
allows the PaC to bootstrap a dynamic PSK to access the current AP.

c) PSK-authenticated networks

d) IEEE 802.1X/EAP-authenticated networks

There is IEEE 802.1X/EAP authentication in this access
network.

Checking the capability information advertised in
IEEE 802.11 Beacon/Probe Response frames (IEEE 802.11i defines
RSN Information Element (IE) for this purpose), PaC can extract
certain information about the different types of networks.

Specifically, if no RSN IE is contained in Beacon/Probe Response frames
then the access network is Type (a). Additionally, Type (d) can be
recognized
because IEEE 802.1X-EAP mode is advertised in the RSN IE.

However Type(b) and Type (c) may not be distinguised by PaC becuase in
both cases
PSK mode is adverstised in the RSN IE. Due to this, the PaC needs to
take an
additional action of trying to associate to the AP.

If either PaC receives a disassociation frame from AP or AP inmediately
starts 4-way handshake after association, PaC can consider network as
Type (c). Otherwise the network is Type (b).

The PaC behavior after identifying an access network Type (b) is
described in Section 10.2, Section 10.2.1 and Section 10.2.2. "

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 Jan 2006 13:25:28 +0200

Hi Rafa,

My comments are inserted below.

> There is no IEEE 802.11i link-layer security in this access network.

I think the highlight of this type is:

"The clients are not authenticated to access these networks."

> allows the PaC to bootstrap a dynamic PSK to access the current AP.

Rather than "There is", I think we shall say "The clients are required to
perform".

> There is no PANA authentication. 

Again, not only PANA but also 802.1X is not used. For that, we should say:

"EAP-based authentication is not used in these networks."

> To access this network AP

> There is IEEE 802.1X/EAP authentication in this access

"The clients are required to perform..." 

> However Type(b) and Type (c) may not be distinguised by PaC becuase in

"distinguished"
"because"

> PSK mode is adverstised in the RSN IE. Due to this, the PaC needs to

"advertised"

> If either PaC receives a disassociation frame from AP or AP inmediately

We shall explain why a PaC would receive a disassociation.... So:

"If either the PaC receives a disassociation frame from the AP as the AP
does not hold a PSK for the PaC, or AP immediately"

> described in Section 10.2, Section 10.2.1 and Section 10.2.2. "

Thanks.

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 13 Jan 2006 10:19:04 -0500

Hi Alper...

Thanks for your comment.

please see inline

>"The clients are not authenticated to access these networks."
Does it mean ipsec cannot be used either?

>Rather than "There is", I think we shall say "The clients are required to
Ok.

>"EAP-based authentication is not used in these networks."
We may say this.  However note that when PSK mode is used networks is 
already implictly said 802.1x/EAP is not used.

>"The clients are required to perform..." 
Ok

>>However Type(b) and Type (c) may not be distinguised by PaC becuase in
Ok

>>PSK mode is adverstised in the RSN IE. Due to this, the PaC needs to
Ok.

>does not hold a PSK for the PaC, or AP immediately"
Ok.

>>>>>>If the network is type (c), wouldn't it try to force the client to 4-
>>>>>>            
>>>>>>
>>way
>>    
>>
>>>>>>handshake? This should come before a DHCP or PANA attempt. So, if the
>>>>>>            
>>>>>>
>>client
>>    
>>
>>>>>>>>>>>However this is not true becuase PaC can distinguish between type
>>>>>>>>>>>                      
>>>>>>>>>>>
>>a)
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>type b) basically
>>>>>>>>>>>becuase type a) network does NOT announce RSN IE in beacon
>>>>>>>>>>>                      
>>>>>>>>>>>
>>frame/probe
>>    
>>
>>>>>>>>>>Does it have to be that way? Can't we design it such that for Type
>>>>>>>>>>                    
>>>>>>>>>>
>>B
>>    
>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>RSN
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>>>>IE
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>if RSN IE does not announce PSK mode... what kind of mode you have
>>>>>>>>>                  
>>>>>>>>>
>>in
>>    
>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>mind
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>to announce?.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>>>>From: [email-masked] [mailto:[email-masked]] On
>>>>>>>>>>>                      
>>>>>>>>>>>
>>Behalf
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>Of
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>Rafa Marin Lopez
>>>>>>>>>>>Considering that classification,  it is said also in this
>>>>>>>>>>>                      
>>>>>>>>>>>
>>section:
>>    
>>
>>>>>>>>>>>"Types (a) and (b) are not distinguishable until the PaC
>>>>>>>>>>>                      
>>>>>>>>>>>
>>associates
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>with
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>the AP ".
>>>>>>>>>>>
>>>>>>>>>>>However this is not true becuase PaC can distinguish between type
>>>>>>>>>>>                      
>>>>>>>>>>>
>>a)
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>type b) basically
>>>>>>>>>>>becuase type a) network does NOT announce RSN IE in beacon
>>>>>>>>>>>                      
>>>>>>>>>>>
>>frame/probe
>>    
>>
>>>>>>>>>>>Actually PaC cannot distinguish between networks where PANA is
>>>>>>>>>>>                      
>>>>>>>>>>>
>>used to
>>    
>>
>>>>>>>>>>>but it is statically configured. In both cases RSN IE announces
>>>>>>>>>>>                      
>>>>>>>>>>>
>>PSK
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>mode
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>in RSN IE.
>>>>>>>>>>>
>>>>>>>>>>>Another thing that could not be clear in the classification is
>>>>>>>>>>>                      
>>>>>>>>>>>
>>the
>>    
>>
>>>>>>>>>>>meaning of IEEE 802.1X-secured network. Are we assuming here both
>>>>>>>>>>>                      
>>>>>>>>>>>
>>IEEE
>>    
>>
>>>>>>>>>>>802.1X authentication with EAP or PSK should be also included
>>>>>>>>>>>                      
>>>>>>>>>>>
>>here?.
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>My
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>understanding of type c) network is EAP authentication is used
>>>>>>>>>>>                      
>>>>>>>>>>>
>>but no
>>    
>>
>>>>>>>>>>>PSK mode is considered.
>>>>>>>>>>>
>>>>>>>>>>>then i would say PaC cannot distinguish between type b) networks
>>>>>>>>>>>                      
>>>>>>>>>>>
>>and
>>    
>>
>>>>>>>>>>>authentication is not included in type c) networks then
>>>>>>>>>>>                      
>>>>>>>>>>>
>>classification
>>    
>>
>>>>>>>>>>>is incomplete , we should add networks that requires a PSK and no
>>>>>>>>>>>                      
>>>>>>>>>>>
>>PANA
>>    
>>
>>>>>>>>>>>Thus I think the section 10.2.3 could be rewritten more clearly
>>>>>>>>>>>                      
>>>>>>>>>>>
>>in
>>    
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>this
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>>>>way:
>>>>>>>>>>>
>>>>>>>>>>>"
>>>>>>>>>>>When a PaC is a mobile, there may be multiple APs available in
>>>>>>>>>>>                      
>>>>>>>>>>>
>>its
>>    
>>
>>>>>>>>>>>There is no IEEE 802.11i link-layer security in this access
>>>>>>>>>>>                      
>>>>>>>>>>>
>>network.
>>    
>>
>>>>>>>>>>>        There is PANA authentication in this access network
>>>>>>>>>>>                      
>>>>>>>>>>>
>>which
>>    
>>
>>>>>>>>>>>        allows the PaC to bootstrap a PSK to access the current
>>>>>>>>>>>                      
>>>>>>>>>>>
>>AP.
>>    
>>
>>>>>>>>>>>        There is no PANA authentication.  To access this network
>>>>>>>>>>>                      
>>>>>>>>>>>
>>AP
>>    
>>
>>>>>>>>>>>Response frames then the access network is Type (a), otherwise it
>>>>>>>>>>>                      
>>>>>>>>>>>
>>is
>>    
>>
>>>>>>>>>>>Type (b).
>>>>>>>>>>>
>>>>>>>>>>>Type (b1) and Type (b2) can be recognized by checking the
>>>>>>>>>>>                      
>>>>>>>>>>>
>>contents of
>>    
>>
>>>>>>>>>>>the RSN IE, i.e., if IEEE 802.1X-EAP mode is advertised in the
>>>>>>>>>>>                      
>>>>>>>>>>>
>>RSN IE
>>    
>>
>>>>>>>>>>>the access network is Type (b1), otherwise if PSK mode is
>>>>>>>>>>>                      
>>>>>>>>>>>
>>adverstised
>>    
>>
>>>>>>>>>>>it is Type (b2).
>>>>>>>>>>>
>>>>>>>>>>>(b21) from Type (b22), the PaC needs to take an additional action
>>>>>>>>>>>                      
>>>>>>>>>>>
>>of
>>    
>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Jan 2006 10:16:48 -0500

> "The clients are not authenticated to access these networks."

When an AP *implementatifon* of type b) does not allow any IP traffic
to pass through uncontrolled port of the AP (a client that does not
have a PSK will view such an AP as type c) in this case), then PANA
may run over type a) network to bootstrap 802.11i for type b) APs.  So
I think Rafa's text seems to be good to cover this "AP-switching"
operation.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 16 Jan 2006 22:10:51 -0500

Hi Yoshi...

>I think Rafa's text seems to be good to cover this "AP-switching"
I think this is another case what we have not considered in the current
text (although it was considered some time ago).

In the case you are describing, I would say (open) AP is part of type b)
network because is used to bootstrap
link layer security in others AP though no link-layer security is
bootstrapped in itself. It would be the "captive portal".

Regards.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 16 Jan 2006 22:28:47 -0500

> bootstrapped in itself. It would be the "captive portal".

Yes, but I don't want to call PANA "captive portal" :) BTW, there may
be (http-based) real captive portal in this open network.

Yoshihiro Ohba