Federated Wireless
Network Authentication
| Kevin Miller • Duke University | |
| kevin.miller@duke.edu | |
| Internet2 Joint Techs | |
| Salt Lake City | |
| February, 2005 |
| 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. |
| 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 | ||
| Federations | ||
| Wireless Security | ||
| 802.1x | ||
| Working Group Activities | ||
| Project Plan: Phase 1, 2 | ||
| Timeline | ||
| Deliverables | ||
| Administrivia | ||
| 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 | ||
| 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 | ||
| 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 / 802.11i: CCMP/AES | ||
| lacking client implementations | ||
| If deploying RF security, WPA as minimum | ||
| 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 |
| 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.. | |
| 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 | ||
| 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 | ||
| 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 | ||
| 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 802.11i pre-authentication | ||
| Phase 1 | ||
| Toplevel RADIUS server in operation: 1Q05 | ||
| Phase 2 | ||
| Early experiments: 3Q05 | ||
| Operational system: 4Q05 | ||
| Documents | ||
| Architecture: 1Q05 | ||
| Phase 1 Engineering: 2/05 | ||
| Phase 1 System Documentation: Ongoing | ||
| Phase 2 Plan: 2Q05 | ||
| Phase 1 System | ||
| Biweekly Conference Calls | ||
| Thursday 11am-12pm: Feb 24, Mar 10 | ||
| 866-411-0013, 0184827 | ||
| salsa-fwna @ internet2 list | ||
| “subscribe salsa-fwna” to sympa @ internet2 | ||