eduroam diagnostics in NTLR, IdPs and SPs

1,310 views

Published on

configuration,diagnostics,eduroam,idp,ntlr,problems,provisioning,sp,radius,roaming

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,310
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

eduroam diagnostics in NTLR, IdPs and SPs

  1. 1. eduroam diagnostics in NTLR, IdPs and SPs Karri Huhtanen Arch Red Oy 13.3.2013 v1.1
  2. 2. Warning• This presentation contains detailed explanations and long sentences with rather small font.• Because of this it is already available also at SlideShare• http://www.slideshare.net/khuhtanen/ eduroam-diagnostics-in-ntlr-idps-and-sps
  3. 3. Background• the amount of failed authentications in eduroam seems big when organisations are looking into NTLR statistics• CSC/Funet asked if Arch Red could list and explain 10 most common reasons while authentication failed for organisations• So we (Arch Red) wrote first few long emails, but decided then to publish our findings in two blog posts, first in Finnish: • http://blog.archred.fi/2013/01/eduroamin-vianselvitys-osa-1.html • http://blog.archred.fi/2013/01/eduroamin-vianselvitys-osa-2-yleisimmat.html• This presentation is about describing those findings in English and even developing those blog posts further
  4. 4. Background• Arch Red runs National Top Level RADIUS (NTLR) for CSC/ Funet and has connected and even provided turn-key eduroam solutions for several Finnish universities• Via our cooperation agreement with Open System Consultants (Radiator RADIUS server), we have helped organisations around the world to join to eduroam• Arch Red also runs the Top Level RADIUS service and authentication services (IdP) for Wireless Tampere community network and several neighboring cities.• This has given us the experience of diagnosing eduroam from the perspective of Top Level RADIUS (TLR), Service Provider (SP) and Identity Provider (IdP)
  5. 5. Top Level RADIUS diagnostics• Do we accept RADIUS requests from source (IdP/SP)?• Do we know where to send them next? (routing) Is there a proper realm in requests?• Does the next hop (ETLR / IdP) accept the proxied RADIUS request, reject or drop them? Is it alive?• Do the RADIUS responses travel properly to opposite direction?• And that’s about it with EAP-packets. All the remaining information about connections is at the IdP.• TLR may not even register those eduroam authentications which hang or are not otherwise responded with accept or reject.
  6. 6. Service Provider Diagnostics• Do we accept RADIUS requests from source (NAS)?• Do we know where to send them next? (routing) Is there a proper realm in requests?• Does the next hop (TLR) accept the proxied RADIUS request, reject or drop them? Is it alive?• Do the RADIUS responses travel properly to opposite direction?• And that’s it with EAP messages. The service provider does not know anything else. It can however in some cases diagnose what is the roaming terminal’s connection quality, which is more than TLR knows.
  7. 7. Identity Provider Diagnostics• So now we know that Identity Provider has all the information to solve major part of its users connection problems.• Unfortunately Identity Provider such as University may not have the experience, knowledge and time needed to utilise that information.• Because of that we collected a short list of issues, which may lead to failed authentications and bad eduroam user experience.• The following problems are not in a particular order, but numbered to help referral.
  8. 8. 1) configuration problems in terminals• user terminals are not configured correctly to work in home eduroam network, they are configured hastily/incompletely in foreign network or there may be typos in usernames/realms• the complex configuration is then not finished or removed but hoped magically to correct itself in some other network• this kind of partially configured client then bombards IdP server with failing authentication requests increasing failed authentication in statistics• even bigger problem are for example failing SSL/TLS tunneling, PEAP and this kind of interrupted or hanging sessions which may not be registered or seen without running IdP servers in debug mode
  9. 9. 2) older devices and supplicant implementations• Old Nokia and Symbian based devices are good bad examples. WPA/WPA2 in them used by default EAP-SIM, EAP-AKA authentication and had to be manually changed to use PEAP/EAP-TTLS etc. If you do not know this problem, be happy that Symbian is dead.• This problem can be seen in SP, IdP and TLR logs with the usual 3gpp realm• Luckily this is going away with better defaults for supplicants, Android, Windows Phone and iPhone use by default username password authentication.
  10. 10. 3) certificate checking problems• Proper certificate installation is hard to do correctly, iOS kinda works, Android is hell and does anyone know how to configure certificate check to Windows Phone?• EAP-TTLS/PEAP+MSCHAPv2 somewhat protects users and IdPs from man-in-the-middle attacks even if server certificate is not checked• Still some supplicants do not allow for example server name to be checked from certificate• In a better world this would be done via SSH style fingerprint checking and user alerted only if RADIUS server host key would be changed.• Incorrectly or half configured certificate checks cause devices to bombard once again IdP servers and may not even show in logs.
  11. 11. 4) periodical password change requirements in IdPs• So IdP requires all its employees and students to change password every 6-9 months?• What happens to all those device configurations with old passwords? What will those devices do?• You see the point?• Our pursuit for single-sign-on has led us to problem where password needs to be so secure that it needs to be changed often. Changing it often then breaks eduroam configurations.• How about if we would just get back to multiple passwords or have a separate eduroam password? Maybe randomized password by device in a style of Google’s passwords per device? Or Certs in the year 2000 maybe? :)
  12. 12. 5) IdPs incorrect/invalid configuration instructions• 5.1) No realm in configuration instructions either in the inner or outer authentication• 5.2) Weaseling out of certificate problems by instructing users not to check server certificate or server hostname• Just google eduroam instructions, you will find a lot of this kind of incorrect instructions• Solution for this might be to shame those organisations to correct instructions or offer only correct official instructions and require IdPs to configure their AAA accordingly.
  13. 13. 6) Bugs in terminal UI or certificate management• Some devices do not allow e.g. configuring preinstalled CA certificates to be allowed to be used for RADIUS server certificate verification (Nokia N900 was one of these)• Some devices make it really hard to install CA certificates (Android)• And some just do not have UI settings for managing certificates, configuring server names checks etc.• Could we shame vendors to also do these properly? Pretty please?
  14. 14. 7) eduroam WiFi network configuration differences• The actual WiFi radio network configuration differences can also cause problems.• Example: Organisation provides eduroam in WPA1/WPA2 compatibility mode. Some devices assume then that eduroam always supports WPA1 and do not accept WPA2 network as eduroam. Then when user tries to configure new WPA2 eduroam network, it cannot be configured as it has the same SSID as the earlier WPA1 profile. (Microsoft Windows 7)• So let’s just decide that eduroam is only pure WPA2, no WPA1, no 802.1X+WEP, no TKIP, no compatibility modes etc. The recommendation is already WPA2, can it be also obligation for pure WPA2?
  15. 15. Conclusions, solutions, suggestions• eduroam CAT solves a lot of these issues and in Stefan Winter’s presentation in this GN3 Workshop there were a lot of nice tests to ensure IdPs work properly• However installing an additional supplicant may interfere with terminal operating systems or other 3rd party clients.• A better approach might be to use operating system specific configuration and provisioning interfaces.• For some mobile devices a generic eduroam / other configuration provisioning app could be more generic solution. The app would then configure or correct the actual operating system settings based on the information received from the eduroam CAT provisioning service. App could also be used for eduroam quality and conformance monitoring as well as problem reporting.
  16. 16. More problems, solutions, questions?
  17. 17. Contact Information• Karri Huhtanen• Arch Red Oy: http://www.archred.com/• Twitter: @khuhtanen• Google+: https://plus.google.com/101610587919646203054/

×