Subject: [Ietf-liaisons] IEEE 802.11 Review Comments on IETF PANA Framework Document Date: Wed, 28 Jun 2006 15:33:47 -0700 From: Stuart J. Kerry Reply-To: stuart@ok-brit.com Organization: OK-Brit To: townsley@cisco.com, jari.arkko@piuha.net CC: hworstell@research.att.com, DStanley@arubanetworks.com, aboba@internaut.com, 'Al Petrick' , ietf-liaisons@ietf.org Dear Mark Townsley, Purpose: To provide comments from IEEE 802.11 Working Group on the PANA Framework document, draft-ietf-pana-framework-06.txt Thank you for the request and opportunity to review draft-ietf-pana-framework-06.txt. The IEEE 802.11 Working Group has reviewed draft-ietf-pana-framework-06.txt and has the following comments: 1. The description of PANA operation in section 10.2.1, “PANA with Bootstrapping IPsec�, assumes that an IEEE 802.11 link layer association is required, and that no link layer security mechanisms (TKIP, CCMP) are used. Based on this assumption, the description of PANA operation with IEEE 802.11 systems seems correct. 2. The description of PANA operation in section 10.2.2, “PANA with Bootstrapping WPA/IEEE 802.11i� describes a mechanism in which an IEEE 802.11 link layer association is required, IEEE 802.11 Pre-shared Key (PSK) security is used, and the PSK is generated as a result of PANA EAP authentication. There are several issues with this proposed mechanism. 1. In an IEEE 802.11 RSN, only EAPOL data frames pass through the uncontrolled IEEE 802.1X port. General data packets, such as ARP, DHCP and PANA protocol packets are dropped at the uncontrolled port, and blocked at the controlled port until successful completion of IEEE 802.1X encapsulated EAP authentication and successful completion of the 4-Way Handshake. The PANA protocol operation described will not work with deployed IEEE 802.11 RSN compliant systems, as all PANA traffic will be silently discarded. 2. In IEEE 802.11 systems, data frames are sent only in State 3, not in any state, as noted in Section 10.2.2, paragraph 5. See IEEE Std. 802.11Ò-1999, Clause 5.5. 3. The IEEE 802.11 RSN framework is extensible, allowing for multiple Authentication and Key Management (AKM) mechanisms to be defined. It seems that a new AKM, in which select data frames such as ARP and DHCP are allowed on the uncontrolled port, would be required to support PANA authentication as described in section 10.2.2. Changes are required to the IEEE 802.11 specification to support the “PANA with Bootstrapping WPA/IEEE 802.11i� solution that is described, contrary to the statement in paragraph 4 of section 10.2.2. 4. PANA operation seems limited to generating a PSK, “Upon successful authentication, the PaC obtains a separate PSK for each AP controlled by the PAA …� In most IEEE 802.11 WLAN deployments, PSKs are shared among the clients associated to an AP. The IEEE 802.11 standard does not require use of shared PSKs; however this is the typical PSK implementation/deployment. IEEE 802.1X/EAP is used in practice to generate per-station keys. 5. An alternative using a “virtual open-access AP� is described in section 10.2.2, in which “upon successful PANA authentication over this AP, the PaC will switch over to another virtual AP to utilize the PANA-derived PSK�. In IEEE 802.11 RSN operaton, the PMK that is derived is part of a PMK Security Association (PMKSA) which includes specific authorizations, and the authorizations used with one AP are not allowed to be used with another AP. In this case, the PANA protocol appears to be delivering the PSKs to use with other APs, providing a configuration function, and configuring the client with the PSKs, rather than establishing a security context that is re-used. This should be clarified in the document. 3. Section 10.2.3, “Capability Discovery� describes how a PaC discovers the RSN capabilities of an IEEE 802.11 WLAN. Today, there is no way to indicate the presence of the “PSK mode bootstrapped from PANA� capability in the RSN Information Element. For your reference, ANSI/IEEE Std. 802.11Ò-1999, as amended by IEEE Std. 802.11a, IEEE Std. 802.11b, IEEE Std. 802.11b-COR1, IEEE Std. 802.11d, IEEE Std. 802.11g-2003, IEEE Std. 802.11h-2003, IEEE Std. 802.11i-2004, IEEE Std. 802.11j-2004 is the current version of the IEEE 802.11 Standard. Please contact Stuart J. Kerry, IEEE 802.11 Working Group chair, Dorothy Stanley IETF Liaison with any questions. We are happy to discuss these comments and potential future work needed in IEEE 802.11 to support PANA operation. Best Regards, Stuart J. Kerry Contact information: Stuart J. Kerry stuart.kerry@philips.com +1 408 474 7356 Dorothy Stanley dstanley@arubanetworks.com +1 630 363-1389 _______________________________ Stuart J. Kerry Chair, IEEE 802.11 WLANs WG c/o: Philips Semiconductors, Inc. 1109 McKay Drive, M/S 48A SJ, San Jose, CA 95131-1706, United States of America. +1 (408) 474-7356 - Phone +1 (408) 474-5343 - Fax +1 (408) 348-3171 - Cell eMail: _stuart.kerry@philips.com_ Web: www.semiconductors.com _______________________________