1 / 17

Federated Wireless Network Authentication

Federated Wireless Network Authentication. Kevin Miller • Duke University kevin.miller@duke.edu 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.

marina
Download Presentation

Federated Wireless Network Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Federated Wireless Network Authentication Kevin Miller • Duke University kevin.miller@duke.edu Internet2 Joint Techs Salt Lake City February, 2005

  2. 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.

  3. 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

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

  5. 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

  6. 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

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

  8. (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

  9. 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

  10. 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..

  11. 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

  12. 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

  13. 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

  14. 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 802.11i pre-authentication

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

  16. Deliverables • Documents • Architecture: 1Q05 • Phase 1 Engineering: 2/05 • Phase 1 System Documentation: Ongoing • Phase 2 Plan: 2Q05 • Phase 1 System

  17. Join the FWNA Group • Biweekly Conference Calls • Thursday 11am-12pm: Feb 24, Mar 10 • 866-411-0013, 0184827 • salsa-fwna @ internet2 list • “subscribe salsa-fwna” to sympa @ internet2

More Related