150 likes | 161 Views
Enable users to roam across campuses using home credentials, reducing need for guest IDs and simplifying authentication. Explore the FWNA project progress, building blocks, policy work, and how to participate. Join the FWNA group for biweekly calls.
E N D
eduroam.usOperational Experiment Kevin Miller • Duke University kevin.miller@duke.edu Andy Rosenzweig • Merit Network andyr@merit.edu ESCC/Internet2 Joint Techs Workshop February 2006
Federated Wireless Auth Vision • Enable members of one institution to authenticate to the wireless network at another institution using their home credentials • Reduce the need for guest IDs • Simplify authentication when roaming • The “roaming scholar” problem
Potential Users • Multi-campus college/university • School with decentralized authN • School system • Regional consortia: GigaPoP, state network • Etc…
FWNA Project Progress • Determined basic specs • RADIUS hierarchy modeled after current European eduroam network • Requires use of 802.1x • Experimental service in place • Top level servers at UTK, Merit • Connecting servers to Europe, Asia • Finalizing “registration” system • Web-based service that will allow new institutions to easily connect
Building blocks • 802.1x required as wireless access method (no captive portal) • Home institutions selects EAP methods appropriate for them • RADIUS used to transport auth requests from visited to home site • Top-level servers route RADIUS requests between sites
eduroam.us RADIUS routing Top-Level Server 1 Top-Level Server 2 RADIUS server at visited institution RADIUS server at home institution Wireless net at visited institution Userid store at home institution
802.1x, RADIUS and EAP Top-Level Server 1 RADIUS server at visited institution RADIUS server at home institution AP EAP client Userid store at home institution
802.1x, RADIUS and EAP • 802.1x and RADIUS serve as transport mechanisms for EAP authentication • 1x and RADIUS facilitate a conversation between two items controlled by the user and his organization: EAP client and campus RADIUS server
Top-level server interaction Top-Level Server 1 Top-Level Server 2 RADIUS configuration and routing data • Top-level servers draw configs from a central store of data, based on registration • Thus they remain in synch, but do not otherwise directly communicate
Connections to others EuropeTop-Level Server USTop-Level Server 1 Austr.Top-Level Server USTop-Level Server 2 Etc..Top-Level Server Each top-level server knows the top-level realms handled by the others
FWNA Policy work • How are visiting users notified of eduroam.us service availability? • What if the home institution’s policies vary from the visited institution? • How do we notify the user if they are a guest? • What kinds of federations need to be built? • What information is logged, by whom?
Things to consider • Can your campus adopt 802.1x? • Would your wireless authentication structure allow for authenticating foreign realms? • Would you allow visiting users onto your normal wireless network? • …or onto a segregated virtual network if authenticated? • Would doing so solve a problem, or enhance learning?
How to take part • If you want to be an experiment site, send email to: • salsa-fwna-ops@internet2.edu • Must be willing to experiment; nothing is plug and play • Important for experimenters to give feedback by way of pointers, local cookbooks, EAP trial info, etc.
Join the FWNA Group • Project website:http://security.internet2.edu/fwna • Biweekly Conference Calls • Thursdays 11am-12pm • Next on 2/23/06 • salsa-fwna @ internet2 list • “subscribe salsa-fwna” to sympa @ internet2