Credits<br />Thanks to other content contributors<br />Jens Haeusser – UBC – technical negotiation slides<br />GEANT & TERENA – Logging and other areas<br />Prior implementors for inspiring the checklist<br />Useful reference sites<br />http://eduroam.ca - Canadian eduroam site<br />http://eduroam.org - Top level eduroam site<br />http://eduroamus.org - US eduroam site<br />2<br />
Use Case – Wireless Access<br />Without eduRoam<br />User arrives, needs to get onto wireless<br />Needs to talk to IT staff to get credential in system created and a password set<br />User waits for account<br />User uses known password, signs into wireless<br />When user is complete, IT should be notified to delete account and terminate access (right?)<br />IT deletes account(right?)<br />Done<br />With eduRoam<br />User arrives, needs to get onto wireless, has eduRoam enabled ID<br />Open laptop<br />User is authenticated to home system and is online<br />Done<br />3<br />
Eduroam impact<br />Reduces <br />effort supporting guest network ids<br />Support calls…How do I…? <br />Guest account footprint in your systems<br />Only available on wireless systems, not others<br />4<br />
How does eduroam work?<br />802.1X - to authenticate clients before allowing access to the network<br />EAP framework – with secure EAP methods to protect user credentials<br />RADIUS - authentication server infrastructure<br />RADIUS proxying – to route authentication requests to a users home institution<br />Separate IP address space – treated as external to institution (compliance with service agreements, etc)<br />End Users have standard internet access with as few filters as possible (if any at all).<br />
Reciprocity - Hallmark of eduroam<br />Eduroam is about you treating guest credentials how you would like to be treated:<br />Just think about what you would like when you travel:<br />No filtered connections<br />No traffic shaping<br />Public IP address (where possible)<br />NAT is not necessarily appropriate, but if you already private IP folks now, probably works out ok.<br />9<br />
Onboarding Process<br />Canada has ~28 of 92 universities on eduroam.<br />US has slightly less in number (25) but 3,000 plus insitutions<br />Eduroam operator:<br />Standard template for connecting new sites<br />Policy sign-off followed by technical implementation<br />Estimated time for Canada federation-level RADIUS server personnel:<br />on-board a new member site: a few hours to two person-days, depending on member site expertise<br />general maintenance: ~one person-day per month<br />Eduroam site:<br />Local implementation from 4 hours to 4 weeks depending on capabilities<br />Skill: operate/install RADIUS on your choice of platform (Cisco ACS, Microsoft NPS, FreeRADIUS) <br />Operational maintenance: same as your AuthN server now<br />15<br />
Important Implementation Decisions<br />Your RADIUS platform<br />Keep it simple and least number of cogs in the machine<br />Running Active Directory? You may already have RADIUS (NPS)<br />Running Cisco ACS? You can use that.<br />Want an alternative commercial platform?<br />RADIATOR is likely your choice – heavily Perl influenced<br />Root servers run RADIATOR<br />Looking for ‘free’?<br />FREE-Radius<br />Need to deal with MS-CHAPv2 properly<br />Recommendation is to split the config for proxying and answering between 2 instances for clarity/diagnosis sake (see Queen’s build)<br />16<br />
About Server Certificate<br />This certificate is on your IdP<br />Users see this & will evaluate authenticity of the passwd validation<br />Self signed is not recommended<br />Would YOU trust it?<br />How do you convince the 1st year student to ascertain it as valid and not a rogue AP doing an attack?<br />17<br />
Module 5: Log Files, Statistics and Incidents<br />
WHY KEEP LOG FILES?<br />Log files are used to track malicious users and to debug possible problems.<br />Aim: provide evidence to government agencies:<br /><ul><li>Offender’s realm and login time.
Cross-reference timestamp from service provider’s auth log with own logs.</li></li></ul><li>A CLOSER LOOK AT LOGGING REQUIREMENTS<br />Let’s look more closely at logging requirements:<br /><ul><li>Network addressing.
IP address allocated to client.</li></li></ul><li>AUTH LOGS<br />Identity Providers must log all authentication attempts, recording:<br /><ul><li>Authentication result returned by authentication database.
Reason for denial or failure of authentication.</li></li></ul><li>AUTH LOGS (2)<br />At what point should logs be kept?<br />After packet reception from client.<br />Before handing off to proxy.<br />After getting reply from proxy.<br />Before sending reply back to client.<br /> Pre-configured modules exist in FreeRADIUS:<br /> auth_detail, pre_proxy_detail, post_proxy_detail, reply_detail<br />
RELIABLE TIME SOURCE<br />All logs must be synchronised to a reliable time source.<br /><ul><li>E.g. using Network Time Protocol (NTP).
SNTP also okay.</li></li></ul><li>TECHNICAL CONTACT<br />Each federation must designate a technical contact:<br /><ul><li>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.</li></li></ul><li>Onboarding Checklist<br />Are the IP addresses accurate?<br />Some servers may be NAT’d<br />CAF requires accurate Ips to configure local Firewall<br />Successful local domain authentication?<br /><you>@<yourdomain>.ca should work without shared secret as it should remain local<br />Do you have proper password storage?<br />If you auth via LDAP, MS-CHAPv2 win7 clients will require a certain password validation technique.<br />Work arounds are available (smbclient), but be sure to review how the password validation occurs<br />Proper ports configured?<br /> (dest:1645,1646)<br />31<br />