Joint Research Activity 5 Task Force Mobility

Transcription

1 Joint Research Activity 5 Task Force Mobility Network authentication with Network Roaming with eduroam Stefan Winter <stefan.winter@restena.lu> TREFpunkt 13, Örebro, Sweden 12 Oct

2 Overview Differences to other network admission techniques Message flow in Communication on first hop: EAP Further communication: RADIUS (et al.) End-to-end security NAS-side: configuration examples Client-side: supplicant overview eduroam RADIUS hierarchies (general) The eduroam hierarchy Policies, Participants Future development (TF-Mobility and JRA5) How to join 2

3 Overview / Differences to other techniques VPN uses ISO/OSI layer 4 (encapsulates payload in UDP or TCP packets)... (higher layers) 4 Transport 3 Network Web-redirection uses layer Link 2 3 (after authentication, IP Physical 1 address gets unrestricted access) Goals: LAN admission control on ISO/OSI layer 2 no IP traffic involved End-to-end security between user device and authentication server Does not enforce a particular authentication mechanism Can impose constraints after authentication and thus provide different service levels on per-user basis 3

4 the big picture performs authentication insists on authentication grants access when ok wants access to internet authentication credentials travel end-to-end internet 4

5 Message flow The standard denotes three roles for devices: Supplicant: the end-user device that wants to enter the network Authenticator: the device to which the supplicant is directly connected (Switch, Router or Access Point) Authentication Server: device that can verify the authenticity of the user and/or his supplicant EAP (supplicant) RADIUS (authenticator) (authentication server) 5

6 Communication at first hop: EAP EAP (Extensible Authentication Protocol) is a container protocol that can carry arbitrary authentication protocols (most well-known for its use in PPP) Supplicant can encapsulate his desired protocol in EAP and send the auth data to the authenticator Data is sent directly on layer 2; therefore, the term EAPoL (EAP over LAN) is used Authentication will only succeed if authentication method is accepted by authentication server(!) When using an auth protocol that encrypts user data, content is opaque to authenticator Q: how does authenticator know of success? 6

7 Communication at first hop: EAP (2) A: gets meta-info from authentication server (supplicant) [ tart EAPoL-S EAPoL d ata (authenticator) uccess EAPoL-S ] ey [EAPoL-K Derive keys for dynamic encryption encapsu lated EAPoL d ata (authentication server) lated u s p a enc data L o P A E -info a t e m + ] 7

8 Communication behind authenticator Authenticator is part of network infrastructure, has IP address Can transfer EAP payload in other protocols to authentication server at arbitrary place Protocols suited for that purpose: TACACS+ (Cisco, deprecated) Diameter (in development) RADIUS (most commonly used) server to use must be configured in authenticator (examples for IOS follow) authentication server evaluates encapsulated EAP payload -or- delegates decision to other authentication servers Delegation done via routing hints as part of user names (this is where eduroam comes in) 8

9 Communication behind authenticator - RADIUS Connection between authenticator and authentication server based on IP address + shared secret (a static trust relationship) RADIUS authentication server validates identity (note: it can easily re-use existing user databases like LDAP, AD, SQL databases, even plain text files) Upon successful authentication, a RADIUS packet Access-Accept is sent, which can be seen by authenticator This packet may contain further information: maximum session time, VLAN for the user, bandwidth restrictions etc. Authenticator evaluates this packet, sets connection parameters and sends the EAP success message to the supplicant 9

10 Protocols within EAP Common protocols within EAP: EAP-TLS: both supplicant and server validate their identity with certificates EAP-TTLS: server presents certificate, establishes TLS tunnel supplicant uses username+password (PAP) PEAP-MSCHAPv2: similar to EAP-TTLS, but additionally encrypts username+password These protocols provide mutual authentication User authentication Server authentication RADIUS server for university.se tunnel using strong cryptography 10

11 Protocols within EAP TLS and TTLS support more privacy for the user: outer vs. inner identity RADIUS packet User-Name = anonymous@dep1.uni.au EAP payload User-Name = han.solo@dep1.uni.au Password = falcon By checking server certificate, the supplicant can verify to whom he is going to send his credentials checking in this sense means that both the certificate must be valid and the Common Name is really the expected one This requires either well-educated users for proper client configuration or means of enforcing the right configuration 11

12 End-to-end security Encapsulating EAP in RADIUS in conjunction with TLS ensures that no intermediate hop can look into traffic Supplicant needs to verify the last hop (authentication server): Is server certificate valid? Is it derived from the root CA in charge? Consult an (offline copy of) CRLs? Is the server name (CN) the expected one? (this needs to be user-configured unlike in HTTPS...) Users need to be well educated to configure their supplicant software properly A possible future: provide a branded client that has fixed settings, so users can connect easily 12

13 NAS-side configuration aaa new-model! aaa group server radius rad_eap server auth-port 1812 acct-port 1813 aaa authentication login eap_methods group rad_eap! radius-server host auth-port 1812 acct-port 1813 key ! dot11 ssid eduroam vlan authentication open eap eap_methods authentication network-eap eap_methods accounting default guest-mode! interface Dot11Radio0 encryption vlan mode ciphers wep128 ssid eduroam 13

14 Client side: supplicant overview 14

15 Client side: supplicant overview (2) SecureW2 (Windows) Separates outer and inner identity, features predistributed profiles for easier configuration) MacOS has a built-in supplicant as well (no screenshots, sorry) Command-line applications: Xsupplicant (Linux) wpa_supplicant (Linux, Windows) Commercial supplicants available as well (Example: Funk Odyssey) 15

16 Resources The standard: Supplicants: SecureW2: XSupplicant: wpa_supplicant: Funk Odyssey: RADIUS servers: FreeRADIUS (Open Source): Radiator (commercial product): 16

17 eduroam The big picture Researchers all across Europe (ideally: the world) should be able to use each other's networks Currently realised with a hierarchy of RADIUS servers for distributed authentication 17

18 eduroam The current RADIUS hierarchy global root.de.lu.nl org1.lu org2.lu.au.... uni.au dep1.uni.au dep2.uni.au authenticator1 authenticator2 18

19 eduroam Delegation of auth decision User names indicate path to authoritative authentication acts as a delimiter between user name (han.solo) and realm (dep1.uni.au) RADIUS messages (with encapsulated EAP payload) traverse hierarchy upward to the root and downward to the auth server in charge Again, intermediate hops can not look into encrypted EAP traffic Each level of hierarchy only needs to know the next level no global propagation of auth server pool necessary All connections are statically configured If a lot of traffic exchanged between certain institutions, shortcuts can be made 19

20 eduroam the non-technical issues Technically, the roaming problem is solved (at least for now, see later slides) Eduroam also addresses non-technical issues: Who can participate? What service levels are granted to roaming users? What if AUPs differ? What happens in a case of network abuse? Per-country legislation? EU legislation? Finally, further development work is done in various areas Find a solution where not all traffic flows through the root server (SPoF) Get away from static connections to allow direct endto-end authentication, but keep trustworthiness Integrate into JRA5 edugain framework 20

21 eduroam participation and services offered Confederation idea means that all participants are peers with equal rights What user groups are allowed? Some countries (like Luxembourg) could establish roaming also for secondary schools (i.e. pupils) Most countries have no means to do that, so it would be against confederation idea to include Rule of thumb: students in higher education, teachers, professors, scientific staff is allowed ( higher education and research ) What services should be granted? According to the local administration of the participating institution 21

22 eduroam Service separation Institution's own RADIUS server can send information like VLAN ids or ACLs to set specific rules for guest users - EAPoL - RADIUS - EAP Authenticator RADIUS server (AP or switch) for university.se RADIUS - EAP han.solo@dep1.uni.au Professor VLAN Guest VLAN Student VLAN RADIUS - EAP RADIUS server for dep1.uni.au 22

23 eduroam AUPs, abuse, the law(s) Every participant has some kind of Acceptable Use Policy in place If the home AUP and the visited AUP differ, only actions that conform to both are allowed If network is abused, user must be blocked Lock out station locally Notification of home network If home network doesn't properly react: block out entire realm Framework must respect European legislation Directive on data protection: ensure that privacy is ensured, dispose of logs after a time Local laws and implementations of EU directive must be respected by participating countries Still open: non-european countries' legislations 23

24 eduroam future development The RADIUS way of delegating requests puts great stress on the root (and possibly TLD) servers Message flow could be optimised: visited site directly contacts home site Several solutions are currently being evaluated: Diameter: a new replacement protocol for RADIUS with peer discovery options Using DNSSEC for service discovery and trust establishment? DNS for discovery and custom extensions to RADIUS for trust ( radsec )? Base network admission decision on more info than just home domain Solve the.edu routing problem 24

25 eduroam future development (2) Integration into the more general edugain framework edugain is an authentication and authorisation infrastructure developed within Geant2 JRA5 Framework that covers not only network admission, but also application access Can integrate Shibboleth, A-Select, PAPI,... Ultimate goal: a Single-Sign-On solution for arbitrary resources 25

26 eduroam How to join Set up country-level server (probably SUNET for.se) Statically connect all institutions that are willing to participate to that.se server Contact root server team for static connection with the root server Technical contacts for various RADIUS server implementations available Administrative contact (policies etc.): Klaas Wierenga, chair of TF-Mobility 26

27 eduroam Resources GEANT2 Joint Research Area 5 TERENA Task Force Mobility Eduroam homepage 27

28 28