doc.: Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Securing the Network Access x over ] Date Submitted: [11 May 2011] Source: [Jonathan Hui and Wei Hong] Company [Cisco Systems, Inc.] Address [170 West Tasman Drive, San Jose, CA USA] Voice:[ ], Re: [WNG] Abstract:[Problem statement and Call to action for supporting 802.1x over ] Purpose:[Presentation to WNG] Notice:This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release:The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

doc.: Submission Securing the Network Access – 802.1x Over Jonathan Hui Wei Hong Cisco Systems, Inc., Slide 2

doc.: Submission IEEE Security Frame Security –Data confidentiality, Data authenticity, Replay protection Network Access Control –Defer to upper layer based on MAC address Security Suites –CCM* mode encryption and authentication transformation –AES block cipher What is specified today?

doc.: Submission IEEE Security Secure Network Access Control Architecture –Supplicant, Authenticator, and Authentication Server Protocols –Security Capabilities Discovery –Authentication –Secure Association/Key management Existing deployments use no or proprietary secure network access What is not specified today?

doc.: Submission IEEE Knows Network Access Control Well-defined Architecture –Supplicant, Authenticator, and Authentication Server Security Capabilities Discovery –RSN Information Element Authentication –Carry Extensible Authentication Protocol (EAP) in EAP over LAN (EAPoL) frames Secure Association/Key Management –EAP-derived PMK  PTK –Use PTK to communicate GTK Leverage IEEE 802.1x and IEEE i

doc.: Submission Typical 802.1x Architecture Authentication Server Authenticator Enforcement Point e.g. RADIUSEAPoL Auth Server: handles access requests from authenticators Access Point: device that performs authentication negotiations and acts as an Enforcement Point Supplicant: a device that wishes gain access to the network Supplicant

doc.: Submission What Needs to be Done Map EAPoL to IEEE frames Define operation where Supplicant and Authenticator are not within direct communication

doc.: Submission Extended for Multihop Networks Authentication Server Authenticator e.g. RADIUSEAPoL over 15.4 EAPoL Tunnel over IP Auth Server: handles access requests from authenticators Authenticator: device that performs authentication negotiations Enforcement Point: a device that has already been admitted into the network by the authenticator Supplicant: a device that wishes gain access to the network Supplicant Enforcement Point

doc.: Submission Why Not PANA? Architectural Issues –Enable (restricted) network-layer communication before allowing link-layer access Still need key management (e.g i) –4-way handshake for PMK  PTK derivation –2-way handshake for GTK distribution No wide-spread deployments

doc.: Submission Summary Problem –Need secure Network Access Control for IEEE Approach –Apply proven IEEE 802.1x and i techniques for: Security Capabilities Discovery Authentication Using EAP Secure Association/Key Management

doc.: Submission Call to Action Specify EAPoL for –Within IEEE ? –Leverage PHY adaptation layer in 15.4k for fragmentation? Specify link operation of Enforcement Point and Authenticator –Within IEEE 802.1? Specify EAPoL Tunnel over IP –Within IETF?

doc.: Submission End