150 likes | 278 Views
eduroam.us Operational 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.
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