Transcript Federated Wireless Network Authentication

Federated Wireless
Network Authentication
Kevin Miller • Duke University
[email protected]
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 / 802.11i: 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 802.11i 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
– 866-411-0013, 0184827
salsa-fwna @ internet2 list
– “subscribe salsa-fwna” to sympa @
internet2