joint research activity 5 task force mobility -...

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

1

Joint Research Activity 5

Task Force Mobility

Network authentication withIEEE 802.1X

Network Roaming with eduroam

Stefan Winter <[email protected]>

TREFpunkt 13, Örebro, Sweden

12 Oct 2005

mailto:[email protected]


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


3

IEEE 802.1XOverview / 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

PhysicalLink

Network

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

1234

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


4

internet

IEEE 802.1Xthe “big picture”

wants accessto internet

insists on authenticationgrants access when ok

performsauthentication

authenticationcredentials travelend-to-end


5

IEEE 802.1XMessage 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 canverify the authenticity of the user and/or his supplicant

(supplicant)

EAP(authenticator)

RADIUS

(authentication server)


6

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


7

➢ A: gets meta-info from authentication server

IEEE 802.1XCommunication at first hop: EAP (2)

(supplicant)

EAPoL-Start

(authenticator)EAPoL data encapsulatedEAPoL data (authentication server)

encapsulated

EAPoL data

+ meta-infoEAPoL-Success

[EAPoL-Key]

Derive keys

for dynamicencryption

[ ]


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.1XCommunication behind authenticator


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.1XCommunication behind authenticator - RADIUS


10

IEEE 802.1XProtocols 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 usingstrong cryptography

Serverauthentication

Userauthentication

[email protected]

RADIUS serverfor university.se


11

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

IEEE 802.1XProtocols 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 packetUser-Name = [email protected]

EAP payloadUser-Name = [email protected] Password = falcon



12

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


13

IEEE 802.1XNAS-side configurationaaa new-model!aaa group server radius rad_eap server 1.2.3.4 auth-port 1812 acct-port 1813aaa 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


14

IEEE 802.1XClient side: supplicant overview


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.1XClient side: supplicant overview (2)


16

IEEE 802.1XResources

➢ 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

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

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


17

eduroamThe “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


18

eduroamThe current RADIUS hierarchy

global root

.de .lu .nl .au . ...

org1.lu org2.lu uni.au

dep1.uni.au dep2.uni.auauthenticator1 authenticator2

[email protected]


19

eduroamDelegation 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


20

eduroamthe 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


21

eduroamparticipation 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


22

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

GuestVLAN

StudentVLAN

ProfessorVLAN

[email protected]

IEEE 802.1X- EAPoL -

RADIUS- EAP -

RADIUS server

for dep1.uni.au

RADIUS- EAP -

RADIUS- EAP -


23

eduroamAUPs, 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


24

eduroamfuture 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


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

eduroamfuture development (2)


26

eduroamHow 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 <[email protected]>



27

eduroamResources

➢ GEANT2 Joint Research Area 5http://www.geant2.net./

➢ TERENA Task Force “Mobility”http://www.terena.nl./mobility/

➢ Eduroam homepagehttp://www.eduroam.org./


28

joint research activity 5 task force mobility -...

Documents