Subject: [Pana] [framework] simplying WLAN section

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 12 May 2004 15:11:53 -0700

I have checked the latest version of IEEE 802.11i/D10.0, and I noticed
that higher-layer data traffic that is optionally allowed to be
received and processed on IEEE 802.1X Uncontrolled Ports does not have
to be terminated between stations (including AP).  Specifically, the
following note in section 8.4.10.1 of IEEE 802.11i/D7.0 was removed
from D10.0:

   Informative Note: STAs may optionally receive frames other than
   IEEE 802.1X messages in unprotected data MPDUs destined for the
   IEEE 802.1X Authenticator's Uncontrolled Port at any time, with the
   caveat that any protocol utilizing this mechanism should provide
   cryptographic data protection mechanisms, suitable for the intended
   application or usage, within the protocol itself.  These frames are
   never forwarded to or from the DS, but terminate at an application
   level service, such as a captive portal, on the AP.  This usage is
   outside the scope of this standard.

This means that in the PANA framework document, (virtual) AP hopping
operation described in 10.2.2.1 is not needed anymore when AP and PAA
are separated, and thus the same operation that was defined for
co-located AP and PAA is now applicable to the separate AP and PAA
case.

Suggested changes:

[1] Change section 10.2.2 to:

"
10.2.2 PANA with Bootstrapping IEEE 802.11i/WPA

   In this model, PANA is used for authentication and authorization,
   and L2 ciphering is used for access control, the latter is enabled
   by the former.  The L2 ciphering is based on using PSK (Pre-Shared
   Key) mode of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i
   [802.11i], which is derived from the EAP MSK as a result of
   successful PANA authentication.  In this document, the pre-shared
   key shared between station and AP is referred to as PMK (Pair-wise
   Master Key).  In this model, MAC address is used as the device
   identifier in PANA.

   This model allows the separation of PAA from APs (EPs).  A typical
   purpose of using this model is to reduce AP management cost by
   allowing physical separation of RADIUS/Diameter client from access
   points, where AP management can be a significant issue when
   deploying a large number of access points.

   By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is
   also possible to improve wireless LAN security by providing protected
   disconnection procedure at L3.

   This model does not require any change in the current WPA and IEEE
   802.11i specifications.  This also means that PANA doesn't provide
   any L2 security features beyond those already provided for in WPA and
   IEEE 802.11i.

   The IEEE 802.11 specification [802.11] allows Class 1 data frames
   to be received in any state.  Also, the latest version of IEEE
   802.11i [802.11i] optionally allows higher-layer data traffic to be
   received and processed on their IEEE 802.1X Uncontrolled Ports.
   This feature allows processing IP-based traffic (such as ARP, IPv6
   neighbor discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled
   Port prior to client authentication.  (Note: WPA and its
   corresponding version of IEEE 802.11i draft do not explicitly
   define this operation, so it may be safer not to use this in WPA).

   Until the PaC is successfully authenticated, only a selected type
   of IP traffic is allowed over the IEEE 802.1X Uncontrolled Port.
   Any other IP traffic is dropped on the AP without being forwarded
   to the DS (Distribution System).  Upon successful PANA
   authentication, the traffic switches to the controlled port.  Host
   configuration, including obtaining an (potentially new) IP address,
   takes place on this port.  Usual DHCP-based, and also in the case of
   IPv6 stateless autoconfiguration, mechanism is available to the
   PaC.  After this point, the rest of the IP traffic, including PANA
   exchanges, are processed on the controlled port.

   When a PaC does not have a PMK for the AP, the following procedure
   is taken:

   1.  The PaC associates with the AP.

   2.  The PaC configures a PRPA by using DHCP (in the case of IPv4) or
       configures a link-local address (in the case of IPv6), and then
       runs PANA by using the address.

   3.  Upon successful authentication, the PaC obtains a PMK for each AP
       controlled by the PAA.

   4.  The PaC performs 4-way handshake to establish a PTK (Pair-wise
       Transient Key) between the PaC and AP, by using the PMK.

   5.  The PaC obtains a POPA by using any method that the client
       normally uses.
"

[2] Remove sections 10.2.2.1 and 10.2.2.2.

[3] Change section 10.2.3 to:

"
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) 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.

   Type (c) is distinguished from others by checking the capability
   information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i
   defines RSN Information Element for this purpose).  Types (a) and
   (b) are not distinguishable until the PaC associates with the AP,
   get an IP address, and engage in PANA discovery.  The default PaC
   behavior would be to act as if this is a free network and attempt
   DHCP.  This would be detected by the access network and trigger
   unsolicited PANA discovery.  A type (b) network would send a
   PANA-Start-Request to the client and block general purpose data
   traffic.  This helps the client discover whether the network is
   type (a) or type (b).  Or if the PaC is pre-provisioned with the
   information that this is a PANA enabled network, it can attempt PAA
   discovery immediately.  The PaC behavior after connecting to an AP
   of type (b) network is described in Section 10.2, Section 10.2.1
   and Section 10.2.2.
"

Comments appreciated.

Yoshihiro Ohba

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 12 May 2004 16:43:23 -0700

Yoshi,

>    Informative Note: STAs may optionally receive frames other than

I am a bit confused by this statement. If this note was removed in the latest draft does it not
mean that "STAs may not receive frames other than IEEE802.1x messages" i.e till
version 7.0 there was a possibility that messages other than IEEE802.1x may be
received and terminated at the application layer, but with 10.0, it can no longer
receive and would be dropped before the application sees it. If so, it would mean
that PANA messages won't be received.  What am i missing ? 

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 12 May 2004 16:43:23 -0700

Yoshi,

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 12 May 2004 20:22:43 -0700

> that PANA messages won't be received.  What am i missing ? 

In other section of D10.0, it says that:

	Within an RSN, this is different. In an RSNA the IEEE 802.1X
	Port determines when to allow data traffic across an IEEE
	802.11 link. A single IEEE 802.1X Port maps to one association
	and each association maps to an IEEE 802.1X Port. An IEEE
	802.1X Port consists of an IEEE 802.1X Controlled Port and an
	IEEE 802.1X Uncontrolled Port. The IEEE 802.1X Controlled Port
	is blocked from passing general data traffic between two STAs
	until an IEEE 802.1X authentication procedure completes
	successfully over the IEEE 802.1X Uncontrolled Port. Once the
	AKM completes successfully, data protection is enabled to
	prevent unauthorized access, and the IEEE 802.1X Controlled
	Port unblocks to allow protected Data traffic. 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.

This means some application traffic can be processed over 802.1X
Uncontrolled Port.  So the removal of the informative note means that
the restriction of PANA traffic termination at an RSN-enabled AP was
removed.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 12 May 2004 20:22:43 -0700

Yoshihiro Ohba

---

From: Rafael Marin Lopez <[email-masked]>
Date: Thu, 13 May 2004 15:49:38 +0200

Hi Yoshihiro

I had a similar doubt... now it is clear... Then text you wrote is good
for me...

Regard...

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

---

From: Rafael Marin Lopez <[email-masked]>
Date: Thu, 13 May 2004 15:49:38 +0200

Hi Yoshihiro

Regard...

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 13 May 2004 09:26:12 -0700

Ok, this text makes it clear. And your original text sounds fine to me.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 13 May 2004 09:26:12 -0700

-mohan