Embed Size (px)
DESCRIPTION
CANARIE-CAF's 1/2 day Technical Workshop slide deck discussion eduroam and implementation profiles and lessons learned.
Citation preview
Credits
• Thanks to other content contributors– Jens Haeusser – UBC – technical negotiation slides– GEANT & TERENA – Logging and other areas– Prior implementors for inspiring the checklist
• Useful reference sites– http://eduroam.ca - Canadian eduroam site– http://eduroam.org - Top level eduroam site– http://eduroamus.org - US eduroam site
2
Use Case – Wireless Access
Without eduRoam• User arrives, needs to get
onto wireless– Needs to talk to IT staff to get
credential in system created and a password set
– User waits for account– User uses known password,
signs into wireless– When user is complete, IT
should be notified to delete account and terminate access (right?)
– IT deletes account(right?)– Done
With eduRoam • User arrives, needs to get
onto wireless, has eduRoam enabled ID– Open laptop– User is authenticated to
home system and is online– Done
3
Eduroam impact
• Reduces – effort supporting guest network ids– Support calls…How do I…? – Guest account footprint in your systems
• Only available on wireless systems, not others
4
How does eduroam work?
• 802.1X - to authenticate clients before allowing access to the network
• EAP framework – with secure EAP methods to protect user credentials
• RADIUS - authentication server infrastructure• RADIUS proxying – to route authentication requests to a
users home institution• Separate IP address space – treated as external to
institution (compliance with service agreements, etc)• End Users have standard internet access with as few
filters as possible (if any at all).
Secure Wireless – 802.1X
April 27th 2010 Canada eduroam Slide 6
1) Negotiate Authentication Method EAP-PEAPv0-MSCHAPv2
2) Certificate Validation Prevents “man-in-the-middle” attack
3) Establish Secure Tunnel Prevents eavesdropping
secure.wireless.ubc.ca
4) Perform authentication through tunnel Using MSCHAPv2
5) Authentication successful Establish encryption, connect to net
Wireless Encryption Established
6) Client acquires IP address (DHCP)
ssid: ubcsecure
id: jdoe
Eduroam - Roaming User
April 27th 2010 Canada eduroam Slide 7
ssid: eduroam
realm: ubc.ca
realm: sfu.ca
realm: ca
Institution Servers
Federation Server
1) Negotiate EAP type EAP-TTLS-PAP2) Outer Request Validate cert.3) Inner Request PAP – through tunnel – secure!
4) Success Establish encryption.
Cert: eduroam.sfu.ca
Establish TLS tunnel
Connect to network
Eduroam – International Roaming
April 27th 2010 Canada eduroam Slide 8
realm: ubc.ca
realm: sfu.ca
realm: ca
Confederation Server
Federation Server
realm: mit.edu
realm: edu
realm: ucla.edu
Reciprocity - Hallmark of eduroam
• Eduroam is about you treating guest credentials how you would like to be treated:
• Just think about what you would like when you travel:– No filtered connections– No traffic shaping– Public IP address (where possible)
• NAT is not necessarily appropriate, but if you already private IP folks now, probably works out ok.
9
eduRoam @ CANHEIT2011 - McMaster
10
Canadian eduRoam Coverage
Province Institution
British Columbia British Columbia Institute of TechnologyCamosun CollegeGreat Northern Way CampusOkanagan CollegeRoyal Roads UniversitySimon Fraser UniversityThompson Rivers UniversityUniversity of British ColumbiaUniversity of Victoria
Alberta Mount Royal UniversityUniversity of AlbertaUniversity of Calgary
Saskatchewan University of SaskatchewanOntario Brock University
Carleton UniversityMcMaster UniversityQueen's UniversityRyerson UniversityUniversity of GuelphUniversity of TorontoUniversity of WaterlooUniversity of Western Ontario
Québec Concordia University
École Polytechnique de MontréalHEC MontréalMcGill UniversityUniversité de Montréal
New Brunswick University of New BrunswickNewfoundland Memorial University
11
Digging into Deployment Details
12
Sample Deployment: Queen’s
13
Platform Choice Configuration Comments• FreeRadius chosen as:• Cisco ACS not around@ the time, • MSFT Radius had 'issues'• RADIATOR largely based on perl but
platform pain removed it fom contention
• configuration for each distinctly separate
• originally used GEANT2 cookbook which configured for eduRoam, but not home instititution.
• IP space is routable
• Solaris requires many dependencies to be compiled in (openssl,openLDAP,SAMBA [msChapV2 so must have])
• Migrating from FreeRadius to Cisco ACS
• - attempts to use F5 LB did not go well enough to pursue all the way to prod
Cisco ACS Config
14
Onboarding Process
• Canada has ~28 of 92 universities on eduroam.• US has slightly less in number (25) but 3,000 plus insitutions• Eduroam operator:
– Standard template for connecting new sites– Policy sign-off followed by technical implementation– Estimated time for Canada federation-level RADIUS server personnel:
• on-board a new member site: a few hours to two person-days, depending on member site expertise
• general maintenance: ~one person-day per month
• Eduroam site:– Local implementation from 4 hours to 4 weeks depending on capabilities– Skill: operate/install RADIUS on your choice of platform (Cisco ACS,
Microsoft NPS, FreeRADIUS) – Operational maintenance: same as your AuthN server now
15
Important Implementation Decisions
• Your RADIUS platform– Keep it simple and least number of cogs in the machine
• Running Active Directory? You may already have RADIUS (NPS)
• Running Cisco ACS? You can use that.
– Want an alternative commercial platform?• RADIATOR is likely your choice – heavily Perl influenced• Root servers run RADIATOR
– Looking for ‘free’?• FREE-Radius
– Need to deal with MS-CHAPv2 properly– Recommendation is to split the config for proxying and answering between
2 instances for clarity/diagnosis sake (see Queen’s build)
16
About Server Certificate
• This certificate is on your IdP• Users see this & will evaluate authenticity of the
passwd validation• Self signed is not recommended
– Would YOU trust it?– How do you convince the 1st year student to ascertain it
as valid and not a rogue AP doing an attack?
17
Problem Solving/Diagnosis
18
Logging
• Cue GEANT Module 5
19
20
Module 5: Log Files, Statistics and Incidents
connect • communicate • collaborate
21
WHY KEEP LOG FILES?
Log files are used to track malicious users and to debug possible problems.
Aim: provide evidence to government agencies:
• Offender’s realm and login time.• Why not provide the User-Name?
–User-Name attribute could be obfuscated.– Outer identity could be anonymous or forged.
connect • communicate • collaborate
22
TRACING THE USER’S REALM (1)
You should keep:
• DHCP or ARP sniffing log.
• RADIUS Authorisation log.
• Clock synchronised with Network Time Protocol (NTP).
connect • communicate • collaborate
23
TRACING THE USER’S REALM (2)
Steps:
• Identify IP address of malicious user.
• Find MAC address in DHCP or ARP sniffing log.
• Find authentication session in Auth log.
• Take realm and timestamp from Auth log.
connect • communicate • collaborate
24
NEXT STEPS
Approach eduroam Operations Team (OT).
• OT can link realm to a home federation.
• Home federation can find user’s identity provider.
• Identity provider can find the user name.
–Cross-reference timestamp from service provider’s auth log with own logs.
connect • communicate • collaborate
25
A CLOSER LOOK AT LOGGING REQUIREMENTS
Let’s look more closely at logging requirements:
• Network addressing.
• Auth logs.
• Reliable time source.
• Technical contact.
connect • communicate • collaborate
26
NETWORK ADDRESSING
Service Providers:
• Should provide visitors with publicly routable IPv4 addresses using DHCP.
– Side-thought: why is NAT considered bad?
• Must be able to find a MAC address from the IP address.
• Must log:
– Time client’s DHCP lease was issued.
– MAC address of client.
– IP address allocated to client.
connect • communicate • collaborate
27
AUTH LOGS
Identity Providers must log all authentication attempts, recording:
• Authentication result returned by authentication database.
• Reason for denial or failure of authentication.
connect • communicate • collaborate
28
AUTH LOGS (2)
At what point should logs be kept?
After packet reception from client.
Before handing off to proxy.
After getting reply from proxy.
Before sending reply back to client.
Pre-configured modules exist in FreeRADIUS:
auth_detail, pre_proxy_detail, post_proxy_detail, reply_detail
connect • communicate • collaborate
29
RELIABLE TIME SOURCE
All logs must be synchronised to a reliable time source.
• E.g. using Network Time Protocol (NTP).
• SNTP also okay.
connect • communicate • collaborate
30
TECHNICAL CONTACT
Each federation must designate a technical contact:
• Must be available via email and telephone during office hours.
• May be a named individual or an organisational unit.
• Cover during absence from work must be provided.
Onboarding Checklist
• Are the IP addresses accurate?– Some servers may be NAT’d– CAF requires accurate Ips to configure local Firewall
• Successful local domain authentication?– <you>@<yourdomain>.ca should work without shared secret as it
should remain local
• Do you have proper password storage?– If you auth via LDAP, MS-CHAPv2 win7 clients will require a certain
password validation technique.– Work arounds are available (smbclient), but be sure to review how
the password validation occurs
• Proper ports configured?– (dest:1645,1646)
31
Issue Escalation
32
connect • communicate • collaborate
33
USER SUPPORT: PROBLEM ESCALATION SCENARIO (1)
visited federation
fed.-level admin.
local institution admin.
user
home federation
fed.-level admin.
local institution admin.
OT
1,2
3
4
connect • communicate • collaborate
34
USER SUPPORT:
PROBLEM ESCALATION SCENARIO (2)
visited federation
fed.-level admin.
local institution admin.
user
home federation
fed.-level admin.
local institution admin.
OT
1,2
3
6
4a
5
4b
4
