Federated Wireless Network Authentication Kevin Miller Duke University Internet2 Joint Techs Salt Lake City February, 2005

Vision Enable members of one institution to authenticate to the wireless network at another institution using their home credentials. Often called the “roaming scholar” problem in HiEd. Wired networks handled as well.

Framing the Solution 802.1x –Often used with WPA or WPA2 (802.11i) –Or middlebox access controller EAP authentication –Exact EAP type selected by home institution, deployed on client machines Phase 1: “Simple” RADIUS peering –Integration with existing authn backend

Topics Federations Wireless Security 802.1x Working Group Activities –Project Plan: Phase 1, 2 –Timeline –Deliverables –Administrivia

Federations Goals of federations –Establish trust between entities –Make assertions about identities (authenticate) and release attributes –Protect user privacy through opaque user handles and controlled attribute release

Federations All are relevant to FWNA –Want to leverage federation trust mechanisms instead of sharing RADIUS keys –Visited sites may want attributes about visiting users (e.g. type of user, mobile number) –Control release of identifiable information

Potential Federations Decentralized School School Systems –State schools, local school districts, etc. Regional consortia: GigaPoP / *REN National consortia: Internet2 International: EduRoam Government: ESNet, NSF, NASA Industry

(Brief) History of Wireless Security No RF security WEP: RC4 –easily broken WPA: TKIP/RC4 –many client, AP implementations WPA2 / i: CCMP/AES –lacking client implementations If deploying RF security, WPA as minimum

Focused on 802.1x only? Concentrate group resources on single strategy Focus on standards-based solution that would provide a single interface for users Enables authn, encryption at edge If necessary, infrastructure could likely be used for non-802.1x

What about Wired? 802.1x on wired is easier than wireless, so it all just works (no active roaming). We’ve just been saying wireless because it gets attention..

FWNA Project Plan Work divided in two phases Phase 1: RADIUS Hierarchy –Initial solution to the problem –Develop knowledge of relevant technology –Understand interoperability issues Relatively straightforward –Exchange RADIUS keys –Interface to existing authn systems using basic RADIUS mechanism

FWNA Phase 2 Phase 2: RADIUS Federation –Leverage existing federations to enable single-hop RADIUS authentications –Enable attribute release through federations Requires development –Interface with Shibboleth for authn, inter-site signing –Single-hop server identifications

Beyond authentication… In many cases today, once authenticated all users obtain same level of service FWNA is about identity discovery We must be able to separately provision services from authn and attributes: –Technical setup (IP address, QoS, ACL, etc..) –Access policy –Billing

Other Areas of Investigation Real Time Diagnostics –Determining cause of authn failure –Requires additional inter-domain data exchange Access Point Roaming –Will cause re-authentication back to home server (additional delay) –Mitigated by i pre-authentication

FWNA Project Targets Phase 1 –Toplevel RADIUS server in operation: 1Q05 Phase 2 –Early experiments: 3Q05 –Operational system: 4Q05

Deliverables Documents –Architecture: 1Q05 –Phase 1 Engineering: 2/05 –Phase 1 System Documentation: Ongoing –Phase 2 Plan: 2Q05 Phase 1 System

Join the FWNA Group Biweekly Conference Calls – Thursday 11am-12pm: Feb 24, Mar 10 – , internet2 list –“subscribe salsa-fwna” to internet2