Joint Research Activity 5 Task Force Mobility Network - - PowerPoint PPT Presentation

Réseau Téléinformatique de l'Education Nationale et de la Recherche

1

Joint Research Activity 5 Task Force Mobility

Network authentication with IEEE 802.1X Network Roaming with eduroam

Stefan Winter <stefan.winter@restena.lu> TREFpunkt 13, Örebro, Sweden 12 Oct 2005

Réseau Téléinformatique de l'Education Nationale et de la Recherche

2

Overview

➢ IEEE 802.1X

➢ Differences to other network admission

techniques

➢ Message flow in IEEE 802.1X ➢ 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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

3

IEEE 802.1X

Overview / Differences to other techniques

➢ IEEE 802.1X 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

Physical Link Network ... (higher layers)

➢ VPN uses ISO/OSI layer 4 (encapsulates payload in UDP or TCP packets)

Transport 1 2 3 4

➢ Web-redirection uses layer 3 (after authentication, IP address gets unrestricted access)

Réseau Téléinformatique de l'Education Nationale et de la Recherche

4

internet

IEEE 802.1X the “big picture”

wants access to internet insists on authentication grants access when ok performs authentication authentication credentials travel end-to-end

Réseau Téléinformatique de l'Education Nationale et de la Recherche

5

IEEE 802.1X

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

(supplicant)

EAP

(authenticator)

RADIUS

(authentication server)

Réseau Téléinformatique de l'Education Nationale et de la Recherche

6

IEEE 802.1X 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?

Réseau Téléinformatique de l'Education Nationale et de la Recherche

7

➢ A: gets meta-info from authentication server

IEEE 802.1X Communication at first hop: EAP (2)

(supplicant)

E A P

• L
• S

t a r t

(authenticator)

E A P

• L

d a t a e n c a p s u l a t e d E A P

• L

d a t a

(authentication server)

e n c a p s u l a t e d E A P

• L

d a t a + m e t a

• i

n f

• E

A P

• L
• S

u c c e s s [ E A P

• L
• K

e y ] Derive keys

for dynamic encryption

[ ]

Réseau Téléinformatique de l'Education Nationale et de la Recherche

8

➢ 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)

IEEE 802.1X

Communication behind authenticator

Réseau Téléinformatique de l'Education Nationale et de la Recherche

9

➢ 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

IEEE 802.1X

Communication behind authenticator - RADIUS

Réseau Téléinformatique de l'Education Nationale et de la Recherche

10

IEEE 802.1X 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

tunnel using strong cryptography

Server authentication User authentication john.doe@university.se RADIUS server for university.se

Réseau Téléinformatique de l'Education Nationale et de la Recherche

11

➢ TLS and TTLS support more privacy for the user: outer vs. inner identity

IEEE 802.1X Protocols within EAP

➢ 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 RADIUS packet User-Name = anonymous@dep1.uni.au EAP payload User-Name = han.solo@dep1.uni.au Password = falcon

Réseau Téléinformatique de l'Education Nationale et de la Recherche

12

IEEE 802.1X 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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

13

IEEE 802.1X NAS-side configuration

aaa new-model ! aaa group server radius rad_eap server 1.2.3.4 auth-port 1812 acct-port 1813 aaa authentication login eap_methods group rad_eap ! radius-server host 1.2.3.4 auth-port 1812 acct-port 1813 key 7 1234....7890 ! dot11 ssid eduroam vlan 12345 authentication open eap eap_methods authentication network-eap eap_methods accounting default guest-mode ! interface Dot11Radio0 encryption vlan 12345 mode ciphers wep128 ssid eduroam

Réseau Téléinformatique de l'Education Nationale et de la Recherche

14

IEEE 802.1X Client side: supplicant overview

Réseau Téléinformatique de l'Education Nationale et de la Recherche

15

➢ SecureW2 (Windows)

➢ Separates outer and inner identity, features pre- distributed 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)

IEEE 802.1X Client side: supplicant overview (2)

Réseau Téléinformatique de l'Education Nationale et de la Recherche

16

IEEE 802.1X Resources

➢ The standard:

http://standards.ieee.org/getieee802/download/802.1X-2004.pdf

➢ Supplicants: ➢ SecureW2:

http://www.securew2.com./

➢ XSupplicant:

http://www.open1x.org./

➢ wpa_supplicant:

http://hostap.epitest.fi/wpa_supplicant./

➢ Funk Odyssey:

http://www.funk.com/radius/wlan/wlan_c_radius.asp

➢ RADIUS servers: ➢ FreeRADIUS (Open Source):

http://www.freeradius.org.

➢ Radiator (commercial product):

http://www.open.com.au./radiator/index.html

Réseau Téléinformatique de l'Education Nationale et de la Recherche

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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

18

eduroam The current RADIUS hierarchy

global root .de .lu .nl .au . ...

• rg1.lu org2.lu

uni.au dep1.uni.au dep2.uni.au

authenticator1 authenticator2 han.solo@dep1.uni.au

Réseau Téléinformatique de l'Education Nationale et de la Recherche

19

eduroam Delegation of auth decision

➢ User names indicate path to authoritative authentication server ➢ @ 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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

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 end- to-end authentication, but keep trustworthiness ➢ Integrate into JRA5 eduGAIN framework

Réseau Téléinformatique de l'Education Nationale et de la Recherche

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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

22

eduroam Service separation

➢ Institution's own RADIUS server can send information like VLAN ids or ACLs to set specific rules for guest users

RADIUS server for university.se Authenticator (AP or switch)

Guest VLAN Student VLAN Professor VLAN

han.solo@dep1.uni.au IEEE 802.1X

• EAPoL -

RADIUS

• EAP -

RADIUS server for dep1.uni.au

RADIUS

• EAP -

RADIUS

• EAP -

Réseau Téléinformatique de l'Education Nationale et de la Recherche

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,

• nly 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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

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

Réseau Téléinformatique de l'Education Nationale et de la Recherche

25

➢ 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

eduroam future development (2)

Réseau Téléinformatique de l'Education Nationale et de la Recherche

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 <klaas.wierenga@surfnet.nl>

Réseau Téléinformatique de l'Education Nationale et de la Recherche

27

eduroam Resources

➢ GEANT2 Joint Research Area 5

http://www.geant2.net./

➢ TERENA Task Force “Mobility”

http://www.terena.nl./mobility/

➢ Eduroam homepage

http://www.eduroam.org./

Réseau Téléinformatique de l'Education Nationale et de la Recherche

28